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1  Introduction 


1 . 1  Ada 

Ada  Is  the  United  States  Department  of  Defense's  (DoDJ 
newest  programming  language.  Ada  was  born  In  an  era  of 
rising  software  costs  and  a  proliferation  of  prograasiing 
languages  within  the  DoD.  To  halt  this  software  crisis,  the 
DoD  developed  Ada.  Ada  was  to  become  the  cossson,  hi9h- order 
programming  language  for  all  organizations  within  the  DoD 
Since  the  majority  of  software  costs  in  the  DoD  were  con- 
nected  with  embedded  systems  IS],  it  is  not  surprising  th«t 
Ada  was  designed  with  real-time  progranasing  In  aind. 

Current  estimates  [18]  show  that  the  DoD  spends  32; 
billion  a  year  on  software  for  embedded,  real -t  tine  compul*: 
systems  for  missile  guidance,  communications  control,  end 
weapons  firing.  This  value  is  growing  at  a  coispound  annuel 
rate  of  17%.  The  Ada  share  of  this  oiarket  Is  Increasing 
Ada  receives  acceptance  and  older  languages  are  phased  out . 
Initially,  Ada  received  staunch  opposition  and  reguireJ  the 
DoD  to  take  steps  to  ensure  Ada's  acceptance. 

DoD  Directives  3405.1  and  3405.2  (21,22)  were  drafted 
and  signed  into  effect  in  1987  making  Ada  the  single,  coesson, 
high-order  programming  language  within  the  DoD.  Addition¬ 
ally,  these  directives  mandated  the  use  of  Ada  in  intel¬ 
ligence  systems,  command  and  control  systems,  and  %feapGns 
systems.  The  North  Atlantic  Treaty  Organization  (HATO^  has 
also  established  policies  that  mandate  the  use  of  Ada  abroad 
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tit.  A4-«  «t;;  >«  z  *.*  ia<9p«4ft  pid?«ci», 

t.  AC  l  *44 1  A<|  t>4<Mf«4A  Ai#«a.c/'»  » p4^€  •  stAtiOA  project, 

AI(D<4»  eil'iAt  4#i'4Aic».  eA4  eif  trettie  centrol  »yeteau». 
WtthtA  CAe  &<a&.  t «»  pro^re*  the  on'boerd, 

eflib«44e4.  (eel  e  lee  i.'««f<4te(  ojreteMi  et  the  Air  force’s 
A4v4Ace4  Tecti^el  flitter,  tne  Area's  Li<)hi  Helicopter 
C4pe(  iuMtA".  4 1 .  4A.4  th*  AdveAced  Tectlcel  Alrcreft  116]. 

The  >' 34Mti  t  tM>At  to  A4e  is  strsn<),  not  only  In  the  United 
itetee  hut  4e(ee4  This  coeskltteent  is  especially 

sCion<s  in  the  e(ee  of  esmedded,  reel-tiee  systems. 

I  *’  t«p(eclse  Coepwtet  i  on 

The  concept  of  iepcecise  coskputetion  is  quite  straight- 
foreecd  C 11-1)1.  for  sosm  applications,  approximate  results 
are  adeqvhSte  when  the  nature  of  the  computation  Involves 
lengthy  computation  timm.  Under  real-time  computation 
constraints,  these  lengthy  computations  may  never  be  able  to 
finish.  Vhen  the  degree  of  accuracy  of  the  intermediate 
result*  ''f  a  cosiputation  is  non-decreasing  as  more  processor 
time  Is  spent  to  obtain  a  result,  the  process  is  called  a 
monotone  process  (131  If  the  sranotone  process  completes 
nornully,  it  will  produce  a  precise  result.  However,  if  the 
monotone  process  times  out  prior  to  completion,  it  produces  a 
result  that  is  not  precise,  or  imprecise.  Although  the 
Imprecise  result  is  not  as  precise  as  originally  desired,  it 
may  still  be  of  use  to  the  application. 
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Acceptable  imprecise  results  can  be  returned  when  the 
structure  of  a  computation  is  iterative  [20].  Many  iterative 
numerical  computations  fall  into  this  category  [15,16]. 

Monte  Carlo  simulation  is  another  prime  iterative  target. 
Monte  Carlo  simulation  has  been  used  to  determine  radiation 
shielding  and  nuclear  reactor  criticality  [9].  An  example  of 
the  Jacobi  method  used  to  solve  linear  systems  of  equations 
and  an  example  of  Monte  Carlo  simulation  used  to  perform 
integration  of  a  curve  are  presented  later  in  this  paper  as 
imprecise  computation  examples.  Iterative  computations  are 
not  the  only  type  of  computation  that  can  be  implemented  as 
an  imprecise  computation.  Additionally,  some  non-iterative 
computations  can  be  reformulated  as  iterative  computations 
and  used  as  an  imprecise  computation  [3]. 

There  are  two  language  primitives  required  by  the 
programmer  to  implement  an  imprecise  computation  application. 
These  primitives  are  "impreturn"  and  "impresult"  [11,12]. 
Impreturn  sends  imprecise  results  and  error  indicators  from 
the  callee  to  the  caller.  Impresult  binds  a  handier  proce¬ 
dure  to  an  imprecise  computation.  The  handler  is  called  to 
"massage”  the  imprecise  result  before  it  is  returned. 

Imprecise  computation  is  especially  applicable  to 
real-time  computer  systems.  Under  severe  time  constraints, 
the  imprecise  computation  will  return  an  imprecise,  though 
correct  value.  It  is  here  that  the  link  between  Ada  and 
Imprecise  computation  lies. 
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1.3  Ada  and  Imprecise  Computations 

There  has  been  no  In-depth,  pubilsned  sccoisp^  i 

in  an  effort  to  correctly  Impleskent  imprecise  computst  i  it. 
Ada.  Although  this  topic  has  been  cursorily  addressed 
[2,13],  no  Immediately  Implementable  solutions  neve  seen 
identified.  The  committment  to  Ada  in  the  teal  *.  ims  sr«n«  ;s 
sharply  growing,  while  the  concept  ot  imprecise  c  omp  w*.  «t  <  c  r. 
continues  to  Increase  Its  following.  By  implement 
imprecise  computations  in  Ada,  the  reel-timm  system  desi^nei 
is  given  a  viable  tool  In  designing  state  o(  the  art,  ra..i,f 
tolerant,  real-tlsM  computer  systemm.  tt  was  fat  this  tesscf 
that  this  research  project  was  urtdertahen. 


4  6««  I  A 

G041*  «a4 

TRl«  (•••4<eA  •!(«(<  CW'44A  vltA  Its.*  ««.*;  »f 
<l4eiA<i  «i;  p«**;»;*  a^^tL**  t«  iik(^  ;]i^t*>v.»« 

cett(^aC*C  l«A»  lA  •C4A4*f4  AA«  ??>.;•  iAic;  'ji4*4  :  *4  ***••». 

e*eis»A  4A«)  C**(  lAs^  it  t*4*it**  04c  ts.*«  Ki* 

•  uppocc*  Ch*  t:at':*4<*  VA^lA^^flA^  p$if‘~cipt»»  o  t  i  M  i  M  *.  .,  c  f. 
iMdiA^,  ««4al4ciey,  •a4  .  tK* 

com^uCaCIoa  l«f»t*««AC*e  l«A  64  •  ••it  atoawi* 

Crv*e  l*  •C(0A4  fJlm0om\  coa*  i4*t  «t  i  on  «>•»  i|;v*n  \ 

c(**eiA«i  «  w«l  l  •crstcttjr*^  ftir*!**.  ?h;*  in  iwtn 

*ouli4  e(«n«;*t«  to  •*••  of  I#**  oA  ch*  pNirf  of  th*  r*«i  tiAw 
9y9C*fli  4*9l4A«(  wfto  «routi4  Utt  ItMCcl  y  'Oi*  th*  iti^r*cia!* 
cosiiutAC  toA  aio4ul*.  T^•  crll*fl«  for  •vAluatln^  vacH 
*ppro4cP>  to  tiiplMMAtlA9  la^r^cl**  coaipvtst  I  on*  in  Ad* 
•voLv«d  (row  th*«*  con* ld*r«t i on* . 

T6*  ovaluatlon  crltvrl*  r«pr«**nt*d  v*rl»d  requirements 
desire*  and  concerns.  Because  this  implementation  would  be 
emplo/ed  in  a  real-time  system,  efficiency  was  a  key  require 
sient.  An  inefficient  is^>lesMntat i on  would  not  be  tolerable. 
Portability  was  another  vital  concern.  Ada  was  desiqned  to 
be  portable.  Because  the  name  ‘‘Ada”  is  trademarked,  no 
dialects  or  subsets  are  leqally  allowed.  The  implementation 
should  in  no  way  rely  on  the  underlying  machine  or  operating 
system.  If  the  implementation  were  too  unruly  or  difficult 
to  understand,  it  would  probably  not  be  utilized.  Therefore 
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MS*  of  piroqrsMilnq  ms  *  ccuclsl  criterion.  It  Is  eesy  to 
find  *  solution  to  *  probi«ai  when  the  constrelnts  on  the 
problesi  ere  chenqed  In  eldstreeai.  Likewise,  It  Is  easy  for 
soaeone  approaching  the  problem  of  IsipleMntlng  Imprecise 
computations  In  Ada  to  come  up  with  an  easy  solution,  but  one 
which  Involves  changes  to  the  Ada  standard.  The  goal  of  this 
research  was  to  Implement  Imprecise  computations  In  standard 
Ada,  without  additions  that  are  contrary  to  the  standard. 
Finally,  the  implementation  would  have  to  produce  correct 
results  according  to  the  tenets  of  Imprecise  computation. 

In  summary,  each  approach  was  analyzed  and  evaluated 
based  on  the  following  criteria:  efficiency;  portability; 
ease  of  programming;  whether  or  not  It  could  be  Implemented 
using  the  current  (standard)  version  of  Ada,  and;  correct¬ 
ness.  Three  general  approaches  to  Implementing  Imprecise 
computations  In  Ada  were  identified. 

2.2  Approaches  to  Implementation 

There  were  three  approaches  to  Implementation  of 
Imprecise  computations  In  Ada  Identified.  Subsequently,  each 
approach  was  analyzed  and  evaluated  based  on  the  criteria 
defined  In  Section  2.1.  The  approaches  Identified  Involved 
shared  memory  and  variables,  asynchronous  transfer  of 
control,  and  atomic  computation  loops. 


2.2.1  9iuif«4 

In  this  Mithsd,  coa(^<«tlM  •hni*  mmrn^tf 

contAlnlnq  common  ‘^^flshlM  s^^eh  *•  ^o^imon  ti«s*  * 

Cl«9  location  would  h«  ootohliohod  wtkofoin  •  fijwj  t***  «k<.4.4S 
Cl«9  o  tlMout  condition.  Tho  coo^^vtotlon  look  wowiO  »>« 
coqulcod  to  chocii  this  tloq  copootsdly  doling  it*  ••wcutich 
This  roquiros  chst  ooch  cooputotion  issk  contom  «  i  i  j 
OMchsnlssi.  Polllnq  not  only  violstos  tho  prlnciplo  cl 
modulscity,  but  It  slso  lassos  slqniticsnt  ovorhosd  it  dcno 
froquontly  onouqh  to  quorsntoo  fsst  rssponso  12).  PoHin^ 
reduces  the  efficiency  of  the  esecutinq  code,  hn  sdditsons} 
problem  lies  in  the  use  of  the  preqme  "SHAHED* .  The  Ads 
standard  (23]  provides  praqma  SHARED  to  allow  two  tasks  to 
communicate  via  shared  variables.  These  shared  variables  at# 
Identified  as  such  by  the  praqsM  SHARED  statement.  This 
ensures  that  the  tasks  are  properly  synchronized  when 
accessing  the  shared  variable.  However,  the  Ada  development 
environment  available  to  us,  the  Verdix  Ada  Development 
System  (VADS),  does  not  implement  the  pragska  SHARED  [24]. 

Due  to  these  insurmountable  problems,  this  approach  was 
rejected  for  implementation. 

2.2.2  Asynchronous  Transfer  of  Control 

There  are  basically  two  different  ways  any  task  can 
influence  another  task.  A  task  can  abort  another  task  or  it 
can  rendezvous  with  it.  The  abort  statement  is  not  an 


•  tt«ctlv«  C««aMAl€4K  I**  «il4  C««  |M 

%m  tm*m  •!  •««€«< !•*  tiw  ill  fw  « tiM »#»♦»•  i* 
totlAlCI**  «  •!  C««BHMkl«4(  »**  mm^00ir**  , 

KIMM*  t«  *•  t««  «*•  t«*«  !•  —  }r*ctti  — »wl|> 

4lll«Clk«<  t4Ma.  t«— t«l  •*!  IMI  fkl*  !•  • 

•  I  «  COAtllCV  IMi  IM  f««l*  •!  IktfvltMl  «*!*<•«*  Iktl* 

cflKlc«l  c«^lo<i«  4Ia4  •»«#<  I*  •  ^#|}»; 

Mfy  w««»l«A  •!  AA«  IIOI.  in#  *f4tUMMl*  «»• 

ol  lMlli»f  !•  •tib*#  !*•»•■  — w»w»f «  «lk|* 

plkM«d  oat  to  to*  A4«  otoo4ot4. 

iOOM  CMOOfClk  Noo  OttOOiiptatf  to  OOCOM^  (IkO  AAO  lAOtl«k« 
■odot  oo4  ottow  o  toot  to  ooyocMoooooty  lotottopt  oootteot 
took.  At  Oolft  Uotvocotty  of  tOclMkOlofy,  tooootcfcoro  l»«vo 
conotcoctod  o  caoto«  taptoMOtot loo  ot  Ado  tool  oltooo 
ooynchconoao  tntorrapto  (191.  tokoc  111  ptooooto  o  pooolOlo 
toplooontot  ton  of  tof>rocloo  coopatot  looo,  Pat  rot  loo  on  o 
non-stondocd  pockoqo  to  ooynchtonoao ty  to  loo  ovcoptlono. 

Both  of  thooo  opproochoo  oro  coopt lood  of  non-otondord  Ado 
ond  honco  oto  not  pcttoblo. 

Aoynchronoaoly  rotolnp  on  oxcoptlon  In  o  coopotot Ion 
would  bo  o  stcoiqhtforwotd  oochonloo  towordo  loplooontinq 
loprociso  coiputotlono  in  Ado.  Unf ortunotolyr  thoto  oiiisto 
no  standard  Ado  %Miy  to  occoopllsh  this.  Any  non-stondord 
solution  would  not  bo  portablo  ond  not  occoptoblo.  This 
approach  was  susMarlly  rejoctod. 
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2  .2  )  Aee«ie  C4M[i9««t4C  lea  Leo^ 

Tni*  e^feecft  •«ect«4  «IC»  inm  coace^t  of  c<4Mtln9  the 
co«9«ie4Kl«A  tee^  M  ea  efaeiie  eait .  tvmi  l»o|^  would  bo 
e(l9^<o4  oocb  itococioa  b)r  «  aoaitoi  («»k  wboa  oulflclont 
eiM  «*«  otfoitoblo  ^«loi  to  It*  4**41iao.  TK#  coonputotlon 
leof  would  aot  bo  tatoicu^tod  oaeo  it  otoftod  tho  cuctont 
Itofotloa  Tfclo  O|^f«oo«h  latcoducod  ottlct  tlbia^  concorn* 
bocouoo  el  tfio  ^flotoaia«o  ol  Cbo  Ado  took  109  oodol  loiploMA- 
tot leao . 

Tho  Ado  tooitbd  oodol  hoo  booo  oboidljr  crlticlbod  duo  to 
It*  otlodod  laofllcloacy.  tho  dooifaoto  ol  tho  aow  Mollllro 
olooilo  (til  optod  aot  to  000  tho  tooilaf  lootvtoo  bocouoo  of 
ccltlcol  tlM  ceaotrolato.  A  tocoat  otodjr  «oo  coaductbd  ty 
•uifoc  oad  htoltoo  If  I  to  dototblao  tho  owoihood  of  Ado 
tooting  loctlltloo.  Tho  oooootoooato  uoto  a*do  oa  o  Olfitol 
Iqulpownt  Coipocotloa  COCO  VAX  ddOO  toaalap  DCC  Ado  v] .  ? . 

Ao  o  booollno,  o  tloplo  procoduto  coll  rodoltcd  11  olcro- 
ooconds.  tot  o  elo^lo,  aea-potoootot  toadotveut  toqvlrod  909 
oicrooocondo .  This  disporltf  ooadotod  o  Judicious  uso  of  tho 
rondoxvouo  In  tho  loploowntotlon  of  lo^tocloo  coopwtot I ono  in 
Ado.  Pot  this  tooson,  tho  otooic  cooputot ion  loop  approach 
uos  btokon  down  Into  a  sjmchronoos  votslon  and  an  asynchro¬ 
nous  vocslon. 

In  both  versions,  a  cooputatlon  task  is  created  that 
porCorofl  the  required  furvction.  This  task  contains  the 
cooputation  loop  that  refines  tho  precision  of  the  result. 
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The  computation  loop  contains  IMPRETURN  statements  that 
return  the  current.  Imprecise  result.  When  the  deadline 
occurs  before  the  computation  loop  achieves  a  precise  result, 
the  appropriate  handler  is  invoked  and  the  computation  loop 
is  stopped.  If  the  computation  loop  runs  to  completion,  it 
signals  via  the  compute  rendezvous  in  the  synchronous  version 
and  via  a  boolean  flag  in  the  asynchronous  version. 

As  the  name  implies,  the  asynchronous  version  does  not 
interfere  nor  does  it  rendezvous  with  the  computation  task. 
The  asynchronous  version  initializes  the  computation  loop 
with  input  parameters  by  way  of  a  TIMER  task.  After  initial¬ 
ization,  the  TIMER  task  starts  the  computation  loop.  The 
loop  continues  unmolested  until  it  either  completes  or  is 
stopped  due  to  the  deadline.  The  TIMER  task  has  a  higher 
priority  than  the  computation  task  which  guarantees  that  the 
TIMER  task  will  execute  when  necessary.  The  TIMER  task 
monitors  the  progression  of  time  as  it  approaches  the 
deadline  by  delaying  a  duration  proportional  to  the  amount  of 
time  left  before  the  deadline.  In  the  meantime,  the  computa¬ 
tion  task  is  storing  imprecise  results  and  error  indicators 
via  the  IMPRETURN  call.  When  TIMER  times  out,  it  grabs  the 
most  recent  copy  of  the  imprecise  results,  invokes  the 
appropriate  handler,  and  then  returns  the  result.  If  the 
computation  loop  completes,  it  signals  via  an  IMPRETURN  call 
with  the  final  result  value  and  zero  error  indicator. 

The  synchronous  version  relies  on  frequent  rendezvous. 


This  version  initisitses  the  coeip^tecioA  witi* 

parameters  and  then  calls  for  a  rendeaveus  wits  the  cesi^f* 
tion  task  each  time  the  compute  loop  is  to  me  esmcutmd  mhen 
the  deadline  occurs,  the  appropriate  handler  is  invesed  and 
the  computation  loop  is  stopped.  If  the  computet len  loop 
runs  to  completion,  it  signals  via  the  compute  entry  call  end 
is  subsequently  stopped. 

Both  versions  have  their  respective  advantages  enc 
disadvantages.  The  synchronous  version  Is  less  efficient 
because  of  the  frequency  of  rendexvous,  but  emlntalns  mere 
control  over  the  computation  loop.  Conversely,  the  asynchro¬ 
nous  version  requires  no  rendezvous  with  the  computation  loop 
and  relies  on  the  run-time  system's  efficient  and  correct 
implementation  of  the  Ada  "delay”  statesMint.  Both  versions 
required  no  modifications  to  standard  Ada.  Efficiency,  a  key 
design  criterion,  was  initially  a  major  detractor  of  the 
synchronous  version.  A  system  spending  more  time  completing 
rendezvous  and  less  time  computing  was  intolerable.  Ho%mver, 
study  of  potential  imprecise  computation  targets  such  as  the 
Jacobi  method  for  solving  linear  systems  of  equations  CIS, 16) 
showed  that  these  computations  may  only  loop  about  10  to  SO 
times  before  a  precise  result  is  calculated.  The  rendezvous 
overhead  is  trivial  compared  to  a  Monte  Carlo  application 
which  might  loop  about  10000  times  before  a  precise  result  is 
obtained.  It  was  apparent  that  both  versions  were  viable 
approaches  to  implementing  imprecise  computations  in  Ada. 
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3  lBpl«Mnt«tlon 
3.1  Ada  8p«ci£iC8 

To  proaote  sound  software  engineering  principles,  the 
data  type  definitions,  variable  declarations,  and  associated 
procedures  of  the  isprecise  computation  system  are  located  in 
a  single,  strongly  cohesive  module.  In  Ada,  such  a  module  is 
knotm  as  a  package.  Further,  because  the  result  type  of  each 
imprecise  computation  is  unique,  the  imprecise  computation 
package  would  have  to  allow  differing  result  types.  For 
example,  the  Jacobi  imprecise  computation  requires  a  3- 
elesMnt  array  of  floating  point  numbers  as  its  result,  while 
the  Monte  Carlo  imprecise  computation  of  the  area  of  a  circle 
merely  requires  a  single  floating  point  number  for  its 
result.  It  would  be  quite  unruly  to  construct  and  maintain 
an  imprecise  computation  package  for  any  conceivable  result 
type.  Fortunately,  Ada  provides  a  means  to  circumvent  this 
situation. 

Ada  provides  the  "generic"  package.  This  allows  the 
designer  to  implement  a  mechanism  without  ties  to  specific 
data  types.  According  to  Booch  151,  generic  program  units 
define  a  unit  template,  along  with  generic  parameters  that 
provide  the  facility  for  tailoring  that  template  to  particu¬ 
lar  needs  at  compilation  time.  At  compile  time,  a  generic 
package  is  instantiated  by  specifying  the  actual  parameters 
to  be  substituted  for  the  generic  parameters,  thus  creating 
an  instance  of  the  package.  Generic  parameters  can  be  types. 


values,  objects,  and/os  subpce^caee  IS). 

One  of  the  generic  pacaeetec  types  Kepteseets  the 
Imprecise  computation,  tecause  It  Is  seeeesscy  toi  the 
imprecise  computation  to  maintain  Its  state  Information,  the 
imprecise  computation  must  be  constructed  as  a  task. 
Accordingly,  one  of  the  generic  parameters  is  the  Imprecise 
computation  tasic  type  and  another  parameter  Is  on  access  type 
that  points  to  the  tasic  type.  Other  generic  parameter  types 
include  the  result  type,  the  error  Indicator  type,  and  the 
input  type.  Generic  parasMter  subprograms  ara  used  to  call 
the  entry  points  In  the  Imprecise  computation  task.  These 
procedures  are  necessary  because  the  Imprecise  computation 
package  has  no  knowledge  of  the  specific  task  structure  until 
instantiation.  Therefore,  the  task  entry  points  cannot  be 
hard-coded  Into  the  Imprecise  computation  package,  even  If 
the  entry  names  are  standardized.  The  actual  procedures 
corresponding  to  the  generic  subprograms  are  simple,  one  line 
programs  that  call  the  appropriate  entry  points.  These  entry 
points  vary  between  the  asynchronous  and  synchronous  impre¬ 
cise  computation  packages. 

Through  the  use  of  the  generic  package,  single  synchro¬ 
nous  and  asynchronous  imprecise  cosputatlon  packages  can  be 
constructed.  At  compilation,  new  instances  of  these  packages 
can  be  created  by  specifying  the  appropriate  generic  param¬ 
eters.  This  allo%rs  the  luxury  of  having  one  asynchronous 
package  and  one  synchronous  package  to  modify  and  maintain. 


but  at  the  sane  time  allowing  unlimited  instances  based  on 
the  specific  computation. 
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3.2  Synchronous  Imprecise  Computation 

The  package  SYNCHROMOUS_IMPRBCISE_COMPUTATIOM  has  been 
implemented  as  a  generic  package.  This  package  is  composed 
of  generic  parameters  required  for  instantiation  and  proce¬ 
dures  visible  from  outside  the  package. 


3.2.1  Generic  Parameters 

The  package  SYMCHRONOUS_IMPRBCISB_COMPUTATION  contains 
the  following  generic  parameter  list: 


type  COMPUTATION  is  limited  private; 
type  COMPUTATION_PTR  is  access  COMPUTATION; 
type  RESULT_TYPE  is  private; 
type  ERROR_INDICATOR_TYPE  is  private; 
type  INPUT_TYPE  is  private; 

with  procedure  INITIALIZE (THEjCOMPUTATION  :  in 

COMPUTATI ON_PTR ; 


INPUT  ;  in 

INPUT_TYPE); 

with  procedure  COMPUTE (THEjCOMPUTATION  :  in 

COMPUTATI ON_PTR; 
COMPUTATI ON_COMPLETE  :  out 
boolean) ; 

with  procedure  HANDLE(THE_COMPUTATIOM  :  in 

COMPUTATI ON_PTR ; 
HANDLER_NUMBER  :  in 

integer; 

LAST_VALUE  :  in 

RESULT_TYPE; 

LAST  ERROR  INDICATOR  :  in 


f*«o«_iitoicAro«_rtPi  i ; 

with  procedur«  STOP(THl_CO«FUTATIOIi  ;  la  COMH/TATI , 

The  type  COMPUTATION  cocresponde  to  the  teak  type  et  the 
desired  imprecise  computation.  The  task  type  eefve«  eo  • 
template  that  is  used  to  create  Instancea  et  task  ohlects 
[51.  In  this  way,  multiple  Imprecise  computation  tasks  may 
be  active  simultaneously.  The  task  type  '.i  declared  s 
limited  type  because  neither  assignment  nor  the  predetliMsd 
comparison  for  equality  and  inequality  are  deClned  tor 
objects  of  task  types  (231. 

The  type  COMPUTATIOM_pTII  provides  an  access  type  ts  the 
task  type  COMPUTATION.  When  a  pointer  ol  type 
COMPUTATION.PTR  Is  allocated  uslnq  the  *new*  statement,  s 
task  in  the  fora  of  task  type  COMPUTATION  is  created.  The 
pointer  variable  now  points  to  the  active  task  and  la  used  to 
reference  the  task  entry  points.  This  pointer  Is  needed  in 
the  Imprecise  computation  packaqe  because  It  effectively 
allows  a  task  to  be  passed  as  an  arquaent  to  a  procedure. 
Actually,  the  pointer  is  beinq  passed  but  the  result  is  the 
same.  In  this  %ray,  an  allocated  pointer  variable  of  type 
COMPUTATION_PTR  is  an  effective  and  efficient  means  of 
manipulating  the  computation  task. 

The  generic  parasMter  RBSULT.TYPB  Is  merely  the  data 
type  of  the  result  that  the  imprecise  computation  generates. 
Here  lies  the  beauty  of  Ada's  generic  facility,  for  any  valid 
data  type  can  be  used  to  instantiate  the  generic  package. 
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Th«  typ«  lliaos_INOICATOS_TyPB  provides  the  means  of  deter¬ 
mining  the  exact  precision  of  an  imprecise  computation's 
result.  It  can  be  Instantiated  with  the  data  type  that  Is 
most  applicable  to  the  Imprecise  computation. 

The  generic  parameter  INPUT^TYPB  Is  the  data  type  used 
to  Initialise  the  computation  task.  Often,  several  items  are 
needed  to  properly  Initialize  a  computation  task.  In  this 
case,  IMPUT^TYPB  should  be  Instantiated  with  a  record  type 
composed  of  the  necessary  Items.  The  remaining  generic 
parameters  In  the  package  SYNCHRONOUS_IMPRECISE_COMPUTATION 
are  generic  subprograms. 

Bach  generic  subprogram  is  needed  In  order  to  rendezvous 
with  various  entry  points  of  the  computation  task.  The  user 
of  the  SYNCHR0M0U8_1MPRECISE_C0MPUTATI0M  generic  package  must 
construct  his  o%m  computation  task  type.  This  task  type  roust 
include  several  entry  points.  An  Initialization  entry  point 
receives  Input  data.  A  compute  entry  point  performs  one  loop 
of  the  computation.  One  or  more  handler  entry  points  are 
required  to  manipulate  the  Imprecise  result.  Finally,  an 
entry  point  to  stop  the  task  is  required  In  lieu  of  the  abort 
option.  The  names  of  these  entry  points  are  not  relevant, 
but  must  be  properly  reflected  in  the  procedures  used  to 
instantiate  the  generic  package.  For  example,  consider  a 
task  type  with  the  following  structure: 

task  type  EXAMPLE  is 

entry  INITIALIZE_THE_TASK( . . . ) ; 
entry  COMPUTE_ONE_LOOP ( . . . ) ; 
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entry  HANDLER ( . . . ) ; 
entry  HALT_THE_TASK ; 
end  EXAMPLE; 

The  procedure  for  stopping  the  task  that  would  be  used  to 
instantiate  the  generic  package  would  look  like  the 
following: 

procedure  STOP_TASK(COMP_PTR  :  in  COMPUTATION_PTR )  Is 
begin 

COMP_PTR . HALT_THB_TASK ; 
end  STOP_TASK; 

Mote  that  the  procedure  can  have  any  name.  At  instantiation, 
the  procedure  name  is  bound  to  the  generic  subprogram  STOP. 

So  whenever  STOP  is  called  in  the  imprecise  computation 
mechanism,  STOPJTASK  will  be  called  at  run-time.  Bach 
generic  subprogram  has  clearly  defined  purposes. 

The  procedure  INITIALIZE  takes  two  parameters, 
THE.COMPUTATION  and  INPUT.  THE.COMPUTATIOM  references  the 
computation  task  calculating  the  imprecise  computation. 

INPUT  is  the  data  required  to  properly  initialize  the 
computation  task.  This  procedure  must  be  instantiated  with  a 
sioqple  procedure  that  merely  requests  a  rendezvous  with  the 
initialization  entry  call  of  the  computation  task. 

The  procedure  COMPUTE  initiates  a  rendezvous  with  the 
compute  entry  point  of  the  computation  task.  Procedure 
COMPUTE  takes  two  parameters,  THB_COHPUTATION  and 
COMPUTATIONjCOMPLETE.  The  former  is  a  pointer  to  the 
computation  task.  The  latter  is  a  boolean  flag  that  is  set 


by  th«  coa9at4eioA  eMb  to  oiott  tho  lMi^s*ciao  ion 

Micluinloa  that  •  ptoctoo  (Molt  hao  boaa  ptoducad.  It  tho 
coaputatlon  taab  do«a  not  ptodoca  a  ptacioo  raoult  by  ica 
daadllna*  a  handlat  task  must  b«  cal  lad. 

Tha  pcocadtica  MAMOLS  lolttataa  a  caadaivoua  with  a 
apacltlad  handlar  aatcy  point  within  tha  coapatatlon  took. 

Tha  pacaaatacs  toe  thio  pcocadaca  aca  Tht_C0MPUTAT10li, 
MANOLtajUmm,  LAIT^VALUI*  and  LAIT jnilOll.lllDlCATOil.  A^aln, 
THl_C0MPUTAT10ll  la  a  polntac  caCaranclnq  tha  coaputatlon 
tash.  Thara  aay  ba  aoca  than  ona  handlar  antry  point  in  tho 
cooputatlon  taak .  Tha  paraMtac  HAWDLtJ) opaclflaa 
which  handlar  antry  point  to  call.  Tha  handlar  antry  points 
aay  ba  laplaaantad  aa  a  faally  of  antry  calla  with  a  discrete 
ran^a  (231.  If  not,  procadura  HAMDLt  will  ba  required  to 
decipher  tha  value  of  MANOLIAJNUMBBK  and  call  the  appropriate 
entry  point.  Tha  paraaatars  LAST_VALUS  and 
LAST_BflROR_INDICATOR  raprasent  the  nost  current  lapreclse 
result  and  error  Indicator  returned  by  the  iaq>recl8e  computa¬ 
tion  task.  They  are  passed  to  the  handler  entry  point  where 
they  can  ba  smdlfiad  if  necessary.  A  modified  Imprecise 
result  and  error  Indicator  Is  saved  In  the  standard  method  by 
Issuing  an  IHPRBTURN  call  at  the  end  of  the  handler  rendez¬ 
vous.  After  a  precise  result  has  been  computed  or  a  handler 
executed,  the  computation  task  must  be  stopped. 

The  procedure  STOP  Initiates  a  rendezvous  with  the  stop 
entry  point  of  the  computation  task.  A  boolean  flag  Is  then 
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s«t  and  aubsaquantly  cauaas  an  exit  from  the  Internal  loop 
atcucture.  Procedure  STOP  requires  one  parameter, 
THBjCOMPUTATION.  This  parameter  is  a  pointer  referencing  the 
computation  task. 

At  compilation  time,  all  of  the  preceding  generic  types 
and  subprograms  are  instantiated  with  the  data  types  and 
procedures  developed  by  the  user.  After  instantiation,  a 
custom  synchronous  imprecise  computation  package  exists  in 
the  user's  library.  Now,  the  user  has  the  capability  of 
accessing  the  procedures  bundled  in  the  synchronous  imprecise 
computation  package. 


3.2.2  Procedures 

There  are  two  procedures  in  the  generic  package 
SYNCHRONOUS.IMPRECISE.COMPUTATION  as  dictated  by  the  tenets 
of  imprecise  computation  (11-131.  However,  the  name  of  the 
procedure  IMPRESULT  has  been  changed  to  IMPCALL  because  it 
seemed  more  fitting  of  its  role.  The  other  procedure  remains 
as  IMPRETURN.  The  procedure  declarations  are  defined  in  the 
generic  package  specification  in  the  following  manner: 


procedure  IMPCALL(THE_COMPUTATION  :  in  out 

COMP  UT AT I ON_P TR ; 

THE_KANDLER  :  in  integer; 

DEADLINE  :  in 

CALENDAR. TIME; 

INPUT  :  in  INPUT_TYPE; 

FINAL_RESULT  :  out 

RBSULT_TYPE ) ; 
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procedure  IMPRETURN( INTERMEDIATB.RESULT  :  In 

RESULT_TyPE; 

ERROR_IMDICATOR  :  in 

ERROR_INDICATOR_TyPE) } 

Procedure  IMPCALL  requires  five  parameters.  Parameter 
THE_COMPUTATI ON  is  a  pointer  to  the  computation  task  that 
will  be  computed  in  an  imprecise  fashion.  In  the  event  the 
computation  task  does  not  complete  before  its  deadline, 
parameter  THE_HANDLER  indicates  which  handler  routine  to 
call.  Parameter  DEADLINE  specifies  the  absolute  time  when 
computation  should  cease.  The  computation  task  is  ini¬ 
tialized  with  the  contents  of  the  parameter  INPUT.  Finally, 
the  out  parameter  PINAL  ..RESULT  is  the  precise  result  if  the 
computation  task  completes,  or  the  imprecise  result  after 
being  passed  through  the  handler  routine. 

Procedure  IMPRETURN  is  the  means  by  which  the  computa¬ 
tion  task  returns  imprecise  results  and  error  indicators  to 
the  imprecise  computation  mechanism.  The  two  parameters  of 
procedure  IHPRETURN  reflect  this  design.  Parameter 
INTERNED I ATE_RESULT  is  the  current  imprecise  result,  while 
parameter  ERROR_INDICATOR  indicates  the  precision  of  this 
result . 

An  imprecise  computation  application  can  only  interface 
with  an  instantiated  imprecise  computation  package  via  the 
two  procedures  IMPCALL  and  IMPRETURN  as  specified  in  the 
package  specification.  The  package  body  contains  the  code 
that  implements  these  two  procedures.  However,  the  data 


21 


types ^  variables,  and  procedures  in  the  package  body  are 
invisible  to  the  user.  These  entities  are  only  visible 
within  the  package  body  itself  (231.  The  package  body  of 
SYNCHRONOUS_IMPRECISE_COMPUTATIOM  contains  two  variables  that 
are  global  within  the  package  body. 

CURRENT_VALUE  I  RESULT_TYPE; 

CURRENT_ERROR_rNDICATOR  :  ERROR_INDICATOR_TYPE; 


These  variables  reflect  the  current  imprecise  result  and  its 
associated  error  indicator.  These  variables  are  updated 
solely  by  the  IMPRETURM  procedure.  Procedure  IMPCALL  is 
implemented  in  the  package  body  of 

SYNCHRONOUS_IMPRECISE_COMPUTATION  in  the  following  way: 


procedure  IMPCALL (THE_COMPUTATIOM  :  in  out 

COMPUTATI ON_PTR ; 

THE.HAMDLBR  :  in  integer; 

DEADLINE  :  in  CALENDAR. TIME; 

INPUT  :  in  INPUT_TYPE; 

FINAL_RESULT  :  out  RESULT_TYPE)  is 

COMPUTATION_COMPLETED  :  boolean; 

TIME_HACK  :  CALENDAR. TIME; 

begin 

I N I T I AL I Z E ( THB.COMPUT AT I ON , 

INPUT); 

loop 

COMPUTE ( THE_COMPUTATI ON , 

COMPUTATI ON_COMPLETED ) ; 
exit  when  COMPUTATION.COMPLETBD; 

TIME_HACK  :>  CALENDAR . CLOCK ; 

if  CALENDAR. '’>'’(TIME_HACK, 

DEADLINE)  then 
HANDLE ( THE_COMPUTATI ON , 

THE.HANDLER, 

CURRENT_VALUE, 
CURRENT_ERROR_IMDICATOR) ; 

exit; 
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end  if; 

end  loop; 

STOP ( THB_COMPUTATIOH ) ; 

FIMAL_RESULT  CURRB)IT_VALUB; 
end  IMPCALL; 

The  algorithm  involved  is  straightforward.  The  computa¬ 
tion  task  is  first  initialized  by  calling  the  procedure 
INITIALIZE.  This  generic  subprogram  in  turn  completes  a 
rendezvous  with  the  computation  task,  passing  it  the  appro¬ 
priate  data  in  parameter  INPUT.  The  algorithm  then  enters  a 
loop.  This  loop  will  be  executed  when  the  computation 
completes  or  the  deadline  is  reached.  First,  the  procedure 
COMPUTE  is  called.  This  generic  subprogram  in  turn  enters 
into  a  rendezvous  with  the  computation  task  at  the  compute 
entry  point.  Remember,  this  rendezvous  causes  the  computa¬ 
tion  task  to  complete  one  Iteration  of  the  computation.  If 
this  causes  the  computation  to  complete,  it  signals  so  via 
the  COMPUTATION_COMPLETED  parameter.  After  COMPUTE  finishes, 
the  loop  will  be  exited  if  the  computation  has  completed.  If 
not,  the  system  clock  is  sampled  and  compared  to  the  dead¬ 
line.  If  the  deadline  has  expired,  the  procedure  HANDLE  is 
called  which  in  turn  initiates  a  rendezvous  with  the  computa¬ 
tion  task  at  the  handler  entry  point.  The  loop  is  exited 
after  the  procedure  HANDLE  completes.  If  the  deadline  has 
not  expired,  control  returns  to  the  top  of  the  loop.  After 
termination  of  the  loop,  procedure  STOP  is  called,  ultimately 
completing  a  rendezvous  with  the  computation  task  at  the  stop 
entry  point.  The  final  precise  or  imprecise  result  is  then 
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copiad  to  tha  paraaatac  FINAL JUMULT  aod  aubaaquantly  paaaad 
back  to  tha  collar. 

Tha  procadura  XKFUTINUI  la  tha  aaaaa  by  which  tha 
coaputatlon  task  raturna  lapraclaa  caaulta  and  acroc  Indlca- 
torn.  Thara  la  no  algorltha  raqulrad  bacauaa  thla  procaaa 
■araly  Involvaa  tha  paaalng  and  aubaa«:tiant  atorlng  of  data. 
This  procadura  la  laplaaMntad  in  tha  following  way: 


procedure  IMPRBTURM(  INTlilM101ATSJ»8ULT  :  In 

RBSULT.TYPB; 

ERROR  INDICATOR  :  In 

BRROR.IMOICATOR  TYPB)  la 


begin 

CURRBMT_VALUB  INTBRMBOIATB  RESULT; 

CURRBMT_BRROR_INDICATOR  BRROR.INDICATOR; 

and  IMPRBTURN; 


The  Input  parameters  IHTBRHBOIATB.RBSULT  and  BRROR.INOICATOR 
are  copied  to  the  hidden  variables  CURRBNT_VALUB  and 
CURRENT JSRROR_I ND I CATOR ,  r es pact 1 ve ly . 

The  complete  package  specification  and  package  body  of 
SyNCHRONOUS_IMPRECISB_CONPUTATIOM  can  be  found  In  Appendix  A. 
Figure  1  presents  the  synchronous  Imprecise  computation 
mechanism  In  a  graphical  manner,  using  the  symbols  defined  In 
(51.  This  approach  to  Imprecise  computations  has  been 
implemented  In  standard  Ada  code  and  should  compile  on  any 
validated  compiler.  The  user  need  only  Instantiate  this 
package  with  his  own  data  types  and  subprograms.  Actual 
Imprecise  computation  examples  using  this  package  are  given 


In  Section  4. 


Pa. 


Package  ActualjComp 


Figure  1.  Synchronous 


se  Computation 
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3.3  Asynchronous  Inprecise  Coaputstion 

The  package  ASYMCHRONOUS.IMPRBCISB.COMPUTATIOM  has  been 
lapleaented  as  a  generic  package.  This  package  is  very 
slailar  to  the  synchronous  lapleaentation  In  teras  o£  user 
Interface,  but  internally  is  quite  different.  Like  the 
synchronous  version,  this  package  is  coaposed  of  generic 
paraaeters  required  for  instantiation  and  procedures  visible 
froa  outside  the  package. 

3.3.1  Generic  Paraaeters 

The  package  ASyNCHRONOUS_IMPRBCISB_COMPUTATIOM  contains 
the  following  generic  paraswter  list: 

type  COMPUTATION  is  limited  private; 
type  COMPUTATION_PTR  is  access  COMPUTATION; 
type  RBSULT.TYPB  is  private; 
type  ERROR.INDICATOR.TYPB  is  private; 
type  INPUT_TYPE  is  private; 

with  procedure  START_COMPUTATION(THB_COMPUTATION  :  in 

COMPUTATION  PTR; 
INPUT  :  in 

INPUT_TYPB); 

with  procedure  HANDLE (LAST_VALUB  :  in  out 

RESULT^TYPB; 

LAST_BRROR_INDICATOR  :  in  out 

BRROR_INDICATOR_TYPB ) ; 

The  generic  data  types  are  identical  to  those  in  the  generic 
package  SYNCHRONOUS_IMPRBCISE_CONPUTATION.  However,  the 
generic  subprograms  are  quite  different.  Not  all  of  the 
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generic  subprogram  In  this  asynchronous  version  are  used  to 
rendezvous  with  the  coB4>utation  task.  The  user  of  the 
generic  package  ASYMCHROMOUS_IMPRBCISB_COMPUTATIOM  eust 
construct  a  task  type  that  contains  a  single  entry  point. 

When  this  entry  point  is  called,  input  data  is  passed  to  the 
task.  After  initialization,  the  task  begins  iterating  and 
producing  imprecise  results.  The  task  proceeds  without  any 
further  interruption  or  rendezvous,  asynchronously. 

The  generic  procedure  8TART_C0MPUTATI0N  is  the  procedure 
called  by  the  imprecise  computation  mechanism  to  initialize 
the  computation  task.  The  computation  task  receives  input, 
initializes,  and  then  starts  iterating.  Procedure 
START jCOMPUTATI ON  requires  two  parameters.  Parameter 
THB_jCOMPUTATION  is  a  pointer  to  an  active  task.  The  neces¬ 
sary  input  data  is  passed  via  parameter  INPUT.  Because  the 
computation  task  type  has  only  a  single  entry  point, 
STARTjCOMPUTATION  is  the  only  generic  subprogram  needed  to 
initiate  a  rendezvous. 

By  virtue  of  the  definition  of  a  rendezvous  [23],  an 
asynchronous  approach  to  imprecise  computations  cannot 
utilize  this  synchronous  mechanism.  In  the  synchronous 
implementation,  handler  entry  points  are  included  in  the 
computation  task  type.  This  is  possible  because  the  synchro¬ 
nous  imprecise  computation  mechanism  closely  governs  the 
executing  computation  task.  However,  in  the  asynchronous 
version,  the  computation  task  is  turned  loose.  When  a 
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deadline  is  reached,  the  iepreclse  result  must  be  IssMdlately 
passed  to  a  handler.  For  this  reason,  the  handler  routine  is 
not  part  of  the  cosq^utation  task  type,  but  is  a  separate 
procedure.  Therefore,  the  generic  procedure  HANDLE  does  not 
require  the  task  pointer  variable  required  by  the  synchronous 
handler.  Also,  the  synchronous  version  includes  a  handler 
number  which  facilitates  the  use  of  entry  families  when  the 
handler  is  an  entry  call.  This  parameter  has  not  been 
included  in  the  asynchronous  version. 

The  generic  procedure  HANDLE  requires  two  parasieters. 

The  parameter  LAST_VALUE  supplies  the  handler  routine  with 
the  last  imprecise  result  returned  via  an  IMPRBTURN  call. 
Likewise,  the  parameter  LASTJBRROR_INDICATOR  provides  a  means 
of  determining  the  precision  of  LAST_VALUE.  Note  that  both 
of  these  parameters  are  of  mode  "in  out".  This  is  necessary 
because  the  asynchronous  handler  is  a  separate  procedure  and 
not  a  part  of  the  task  environment  as  it  is  in  the  synchro¬ 
nous  version. 

When  the  preceding  generic  types  and  generic  subprograms 
are  instantiated  with  appropriate  data  types  and  procedures 
at  compilation  time,  a  custom  asynchronous  imprecise  computa¬ 
tion  package  is  created  and  placed  in  the  user's  library. 

This  package  contains  the  bundled  procedures  that  form  the 
crux  of  the  asynchronous  imprecise  computation  mechanism. 
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3.3.2  Procedures 

In  accordance  with  the  theory  of  imprecise  computations 
(11-131,  there  are  two  visible  procedures  in  the  generic 
package  ASYNCHRONOUS_IMPRBCISBjCOMPUTATION.  Like  the 
synchronous  version,  the  name  of  the  procedure  IHPRBSULT  has 
been  changed  to  IMPCALL.  The  other  procedure  remains  as 
IMPRBTURN.  The  procedure  declarations  are  defined  in  the 
generic  package  specification  in  the  following  manner: 


procedure  IMPCALL(THB_COMPUTATION  :  in  out 

COMPUTAT I ON_PTR ; 

DEADLINE  :  in 

CALENDAR. TIME; 

INPUT  :  in 

INPUT.TYPB; 

PINAL  RESULT  :  out 

RESULT_TYPB); 

procedure  IMPRBTURN ( I NTBRMBDIATB.RBSULT  :  in 

RBSULT.TYPB; 

BRROR_INDICATOR  :  in 

BRROR_I NDI CATOR_TYPB; 
STOP_PLAG  :  in  out 

boolean ) ; 


Procedure  IMPCALL  requires  four  parameters.  The 
parameter  THBjCOMPUTATION  is  a  pointer  to  the  imprecise 
computation  task.  Parameter  DEADLINE  specifies  the  absolute 
time  when  computation  should  cease.  The  computation  task  is 
initialized  with  the  value  of  parameter  INPUT.  Lastly,  the 
final  result  of  the  computation,  whether  precise  or  impre¬ 
cise,  is  received  via  the  parameter  PINALJRBSULT. 

Procedure  IMPRBTURN  is  called  by  the  computation  task  in 
order  to  return  an  Imprecise  result  and  its  associated  error 
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Indicator.  The  first  tvo  parsMtars^  IMTBRMIDIATB_RBSULT  and 
BRROR_IHDICATOR,  carry  tha  lapracisa  rasult  and  arror 
indicator  froa  tha  coaputation  taak  to  tha  asynchronous 
iaprecise  coaputation  aechanisa.  Unlika  tha  XNPRBTURM  in  tha 
synchronous  version,  this  IHPRBTURN  contains  a  third  para- 
aeter.  The  paraaeter  STOP_PLAG  functions  as  a  two-way 
cooaiunication  flag  bettraen  the  coaputation  task  and  the 
asynchronous  iaprecise  coaputation  aechanisa.  If  the 
coaputation  taak  achieves  a  precise  result,  it  issues  an 
IHPRBTURM  call  with  STOP.PLAG  set  to  "true**.  If  the  deadline 
has  occurred,  the  coaputation  taak  is  signalled  to  stop  via 
STOPJPLAG  when  the  next  IHPRBTURN  call  is  Issued.  In  this 
%fay,  the  asynchronous  iaprecise  coaputation  aechanisa  docui 
not  have  to  explicitly  stop  the  cooiputation  task.  It  aerely 
sets  a  flag  which  is  comaunicated  to  the  task  when  the  task 
aakes  its  next  IMPRBTURM  call.  The  package  body  contains  the 
code  that  iapleaents  these  aechanisas. 

In  addition  to  the  procedure  bodies  for  IMPCALL  and 
IHPRESULT,  the  ASYNCHROMOUS_IMPRBCISE_COHPUTATION  package 
body  contains  other  variables  and  a  task.  These  entities  are 
not  visible  to  the  user  of  the  package.  They  are  only 
visible  within  the  package  body  itself  [231.  This  package 
body,  because  it  eabodles  the  implementation  of  a  concept,  is 
quite  different  from  the  synchronous  version.  The  following 
variables  are  included  in  the  package  body: 

CURREMT^VALUB  :  RBSULT_TYPB; 
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CURRBMT_ERROR_INDICATOR  :  BRROR.INDICATOR.TYPE; 

STOPjCOMPUTATION.FLAG  :  boolean  :«  FALSE; 

The  variables  CURREMT.VALUE  and  CURRENT_ERROR_INDICATOR  hold 
the  last  imprecise  result  and  error  Indicator  sent  by  the 
IMPRETURN  call.  These  variables  are  updated  by  the  procedure 
IMPRETURN  in  the  course  of  computation  or  the  procedure 
HANDLE  when  the  deadline  has  expired.  The  variable 
STOP_COMPUTATlON_FLAG  Is  a  boolean  flag  that  holds  the 
current  state  of  the  computation.  The  flag  Is  Initially  set 
to  "false",  so  the  conqputatlon  Is  not  to  be  stopped.  The 
flag  will  be  set  to  "true"  when  the  deadline  expires  or  when 
the  computation  task  achieves  a  precise  result.  If  the 
deadline  expires,  the  flag  Is  set  by  the  asynchronous 
Imprecise  computation  mechanism.  If  a  precise  result  Is 
achieved,  the  flag  Is  set  during  a  call  to  procedure 
IMPRETURN.  A  local  task  is  also  contained  in  the  package 
body  of  ASYNCHRONOUS.IMPRECISBjCOMPUTATION. 

While  the  computation  task  Is  iterating  towards  a 
precise  result.  It  Is  necessary  to  have  another  task  moni¬ 
toring  the  system  time  as  the  deadline  approaches.  This 
monitor  has  been  implemented  as  a  task  because  it  requires 
the  use  of  task  priorities.  If  this  monitor  were  Implemented 
as  a  called  procedure.  It  could  not  be  assigned  a  priority 
123].  During  the  period  of  Imprecise  computation,  there  are 
two  tasks  In  the  application  executing.  The  computation  task 
is  computing  Imprecise  results  while  the  monitor  task  Is 
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checking  the  deedline  end  then  delaying.  It  la  neceasacy  for 
the  BMnltor  tank  to  have  a  higher  priority  ao  that  %rhen  the 
deadline  occura,  the  awnltor  teak  geta  iMaedlate  control  of 
the  proceaaor.  The  Monitor  teak  in  the  package  body  of 
ASYMCHROMOUS_IMPRBCISB_COMPUTATION  haa  the  following  teak 
apeclflcatlon: 

task  TIMBR  Is 

pragaa  PRIORITY (7); 

entry  RUN_JOB(THB  JOB  :  in  out  COMPUTATION_PTR; 

INPUT  :  in  IMPUT_TYPB; 

DBADLIMB  :  in  CALBMDAR.TIHB) ; 

end  TIMER; 

The  amnitor  task  has  been  called  task  TIMBR  to  reflect  its 
function.  The  first  stateoMint  of  the  specification  sets  the 
task  priority  to  1,  the  highest  priority  allowed  by  the  VAD8 
software  used  for  developnent  (241.  It  is  inperative  that 
the  user  include  the  following  stateawnt  in  the  computation 
task: 

pragma  PRIORITY(O); 

This  will  ensure  that  task  TIMBR  can  gain  control  of  the 
priority-driven  processor. 

Task  TIMBR  contains  a  single  entry  point  called  RUN_JOB. 
This  entry  point  is  called  from  procedure  IMPCALL  when  It 
wants  a  particular  computation  task  executed  as  an  Imprecise 
computation.  Bntry  point  RUM_JOB  receives  three  parameters 
from  procedure  IMPCALL  during  the  rendezvous.  The  parameter 
THB_JOB  Is  a  pointer  to  a  computation  task.  The  computation 


task  is  initialized  with  the  information  stored  in  INPUT. 
The  parameter  DEADLINE  informs  task  TIMER  of  the  point  in 
time  when  a  result  is  expected.  The  backbone  of  the  asyn¬ 
chronous  approach  to  imprecise  computation  is  the  body  of 
task  TIMER. 

The  task  body  of  task  TIMER  from  the  package  body  of 
AEYNCHRONOUS_IMPRECISE_COMPUTATIONS  has  been  implemented  in 
the  following  a»nner: 


task  body  TIMER  is 

boolean; 
CALENDAR. TIME; 
float; 
DURATION; 


:  in  out  COMPUTATION_PTR; 

:  in  INPUT_TYPE; 

:  in  CALENDAR. TIME)  do 
STARTjCOMPUTATI ON ( THE_JOB ,  I NPUT ) ; 
loop 

TIMB.HACK  CALENDAR. CLOCK; 

TIME_LEFT  ;»  float(CALENDAR. (DEADLINE, 

TIME_HACK) ) 

DELAY_TIME  :«  DURATxOMiTins  Lisi; T  /  2.0); 
if  DELAY_TIME  <  DURATION ' SMALL  AND  THEN 
DBLAY_TIME  >  0.0  then 
DELAY_TIME  :»  0.0; 
end  if; 

if  DELAY.TIME  >  0.0  then 
delay  DELAYJTIMB; 
else 

STOP_COMPUTATION_FLAG  :»  TRUE; 

HANDLE ( CURRENT.VALUB, 

CURRENT_ERROR_INDICATOR) ; 

end  if; 

exit  when  STOP_COMPUTATION_FLAG; 
end  loop; 
end  RUN_JOB; 
end  TIMER; 


COMPUTATION_COMPLBTBD  : 
TIMB_HACK  ; 

TIME_LEFT  : 

DELAY_TIME  : 

begin 

accept  RUN_JOB(THE_JOB 
INPUT 
DEADLINE 


The  body  of  task  TIMER  is  basically  one  rendezvous.  Proce- 
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dure  IHPCALL  calls  the  RUN_JOB  entry  point  o£  task  TIMER  when 
an  asynchronous  imprecise  computation  task  is  to  be  run. 

Task  TIMER  then  initializes  and  starts  the  computation  task 
by  calling  the  generic  procedure  START_COMPUTATION.  After 
entering  the  main  loop,  the  system  clock  is  sampled  and 
compared  to  the  deadline.  The  time  remaining  is  used  to 
compute  a  delay  amount.  Task  TIMER  will  suspend  itself  via 
the  "delay"  statement  if  sufficient  time  remains  before 
deadline.  If  the  deadline  has  expired,  the  flag 
STOP_COMPUTATION_PLAG  will  be  set  so  that  during  the  next 
IMPRETURN  call  the  computation  task  will  terminate  itself. 

The  generic  procedure  HANDLE  will  then  be  called  and  the  loop 
exited.  If  the  computation  task  achieves  a  precise  result 
and  subsequently  signals  via  the  procedure  IMPRETURN,  the 
flag  STOP_COMPUTATIOM_PLAG  will  be  set  and  the  loop  exited. 
When  the  loop  is  exited,  the  rendezvous  completes,  task  TIMER 
terminates,  and  the  final  result  is  left  stored  in  the 
variable  CURRENT.VALUB . 

Note  that  the  variable  OBLAY_TIMB  is  assigned  a  duration 
value  that  is  only  one-half  of  the  time  remaining  before  the 
deadline.  This  heuristic  is  necessary  because  of  an  anomaly 
with  the  "delay"  statement.  The  statement 

delay  1.0; 

suspends  the  task  for  at  least  one  second.  However,  there  is 
no  guarantee  on  the  upper  bound  of  the  delay.  While  task 
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TIMER  is  delaying  itself,  the  coeputation  task  has  control  of 
the  processor.  When  TIMER'S  delay  is  co■^>lete,  task  TIMER  is 
ready  to  be  run  again.  Because  TIMER  was  given  a  higher 
priority  than  the  coeputation  task,  task  TIMER  should  gain 
control  of  the  processor.  Hotraver,  the  scheduler  only  checks 
the  list  of  ready  tasks  at  a  specified  frequency.  VAD8 
checks  at  one  second  intervals  124).  This  ties  slice  is  such 
too  large  for  real-tiee  systeas.  Digital  Eguipeent  Corpor¬ 
ation's  (DEC)  VAX  Ada  provides  the  statement 

pragsa  TIMB_SLICE(static_expression) ; 

where  static^expression  is  a  duration  aeount  in  seconds  (SI. 
The  DEC  suinual  (8)  points  out  that  the  aaK>unt  of  scheduling 
overhead  needed  to  support  round-robin  task  scheduling 
increases  as  the  value  of  a  tis*  slice  decreases.  The 
Binisuia  recoHsended  ties  slice  is  0.01  seconds.  A  test  was 
constructed  to  evaluate  this  feature  and  the  effects  of 
background  tasks  on  the  delay  stateeent. 

In  order  to  detereine  the  effect  of  background  tasks  on 
the  delay  statesMnt,  the  procedures  DBLAY_TEBT  and 
DBLAyjTEST_NO_TAflK  were  designed.  These  procedures  were  run 
on  a  VADS  coaputer  systea  and  then  augaented  with 

pragma  TIMB_SLICB( 0 . 01  or  1.00); 

and  run  on  DEC  Ada  siachines  to  investigate  the  best  perfor¬ 
mance  (0.01)  and  to  cosipare  the  DEC  Ada  run-time  system  with 
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th«  VAD8  run-tlM  systM  (1.00).  Th«  procedure 
0ILAy_T18TJM0_TA8K  waa  conatructad  In  th«  Collowinq  way: 


with  CALMOAS;  uaa  CALIMDAB; 

with  TBXT.XO;  uaa  T8XT  10; 

with  FLOAT  10;  uaa  FLOAT  10; 

procadura  OFLAY.TEaT JIO.TASK  la 

HACXl,  HACX2  :  tlaa; 

TOTAL  :  float  :•  0.0; 


ba^ln 

foe  COUNT  ini..  100  loop 
HACXl  clock; 
dalay  1.0; 

HACX2  :•  clock; 

TOTAL  TOTAL  ♦  float (HACX2  >  HACXl); 
put(*Tlaa  dlffaranca  for  1  aacond  dalay«>*'); 
put (float (HACK 2  -  HACXl)); 
put_llna("  aaca.”); 
and  loop; 
naw_llna( 3); 

put ( "AVBKAOS  DELAY  VAS  ->  ”); 
put(TOTAL  /  100.0); 
put_llna(”  aaca."); 
and  0BLAY_Tt8T_N0_TASK; 

Thla  procedure  merely  aamplea  the  ayatem  clock  before  and 
after  a  one-aecond  delay  atateaent.  The  actual  delay  la 
averaged  over  100  delay  atateawnta.  The  procedure  DBLAY_TBST 
Includea  a  background  tank: 


with  CALENDAR;  uae  CALENDAR; 

with  TEXT_IO;  uae  TEXT_I0; 

with  FLOAT_IO;  uae  FLOAT_IO; 

procedure  DELAY_TEST  la 

pragma  PRIORITY(7); 

HACXl,  HACK2  :  time; 

TOTAL  :  float  0.0; 

taak  BAT  is 

pragma  PRIORITY(O); 
entry  STOP; 
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end  BAT; 

task  body  BAT  is 

COUNT  :  integer  :■  0; 

FINISHED  :  boolean  :■  false; 
begin 

loop 

select 

accept  STOP  do 

FINISHED  t>  true; 
end  STOP; 

else 

COUNT  COUNT  *  1; 
end  select; 
exit  when  FINISHED; 
end  loop; 
end  BAT; 

begin 

for  COUNT  in  1  ..  100  loop 
HACKl  :■  clock; 
delay  1.0; 

HACK2  :>  clock; 

TOTAL  :«  TOTAL  *  float (HACX2  -  HACKl); 
put("TiMe  difference  for  1  second  delay>>''); 
put (float (HACK 2  -  HACKl)); 
put_line(''  secs."); 
end  loop; 

BAT. STOP; 
new_line(3); 

put("AVBRAGB  DELAY  WAS  «>  "); 
put(TOTAL  /  100.0); 
put_Hno("  secs."); 
end  DBLAY.TBST; 


Note  that  the  task  BAT  has  a  lower  priority,  thus  simulating 
the  asynchronous  imprecise  computation  task.  Both  of  these 
procedures  were  run  on  a  VAX-11/780  under  VADS,  a  VAX-11/780 
under  DEC  VAX  Ada,  and  a  VAX  8700  under  DEC  VAX  Ada. 
Additionally,  the  DEC  VAX  Ada  tests  incorporated  the  time 
slice  pragma.  The  average  delays,  in  seconds,  for  a  one 
second  delay  statement  are  summarized  in  Table  1.  The  VERDIX 
system  did  not  perform  well  in  comparison  to  the  DEC  config¬ 
urations.  Even  with  TIME  SLICE  set  to  one  second  in  an 
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CONFIQURATIOM 
VAX  Ada 

TIMB.SLICB(l.OO) 

Average 


Standard 

Deviation 

Var lance 


VAX  Ada 

TIMB_SLICB(0.01) 

Average 


Standard 

Deviation 

Variance 


1.00995(8700) 

1.01796(11/780) 

0.0(8700) 

0.01866(11/780) 

0.0(8700) 

0.00035(11/780) 


1.00995(8700) 

1.01676(11/780) 

0.0(8700) 

0.00469(11/780) 

0.0(8700) 

0.00002(11/780) 


1.00995(8700) 

1.00995(11/780) 

0.0(8700) 

0.0(11/780) 

0.0(8700) 

0.0(11/780) 


1.00995(8700) 

1.01005(11/780) 

0.0(8700) 

0.001(11/780) 

0.0(8700) 

0.000001(11/780) 


1.27862(11/780) 

0.23124(11/780) 


0.05347(11/780) 


VERDI X  Ada 
Developaent  System 

Average  1.84434(11/780) 

Standard  1.13453(11/780) 

Deviation 

Variance  1.28716(11/780) 


Table  1.  Comparison  of  Configurations 
and  Task/Mo  Task  Option 


effort  to  mimic  the  VADS  Inherent  time  slice  the  DBC  Ada  run¬ 
time  system  clearly  performed  better. 

It  Is  apparent  that  some  Ada  run-time  systems  are  better 
geared  for  real-time  applications.  A  serious  real-time 
designer  would  not  Implement  his  hard,  real-time  system  In  an 
Ada  development  system  such  as  VADS.  In  proving  the  via- 
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billty  of  the  package  A8YMCHRONOU8_XMPRBCI8B_COMPUTATION,  it 
becaM  obvious  that  the  testing  i#ould  have  to  be  accoapllshed 
within  the  reale  of  a  genuine,  real-tlee  Ada  developeent 
system.  The  package  body  ho%fever  still  contains  standard  Ada 
code. 

The  procedure  body  for  procedure  IMPCALL  in  the  package 
body  of  ASYMCHROMOUS.IMPRBCISBjCOMPUTATION  is  Implemented  in 
the  following  manner: 


procedure  IHPCALL(THBjCOMPUTATIOM  :  In  out 

COMPUTATI OH_PTR ; 
DBAOLINB  :  in 

CALBMDAR.TIMB; 
INPUT  :  in 

IMPUT_TYPB; 

PINAL.RBSULT  out 

RBSULT.TYPB)  is 

begin 

TIMBR.RUM  JOB(THB_COMPUTATIOM, 

INPUT, 

DBADLINB); 

FINAL  RBSULT  CURRBNT  VALUB; 
end  IMPCALL; 


Procedure  IMPCALL  first  calls  the  RUN_JOB  entry  point  of  task 
TIMBR,  passing  it  a  pointer  to  the  computation  task  to  run, 
the  initialization  input,  and  the  deadline.  Procedure 
IMPCALL  reMins  in  the  rendezvous  with  task  TIMBR  until  a 
final  result  is  produced.  Remember,  when  task  TIMBR  ter¬ 
minates,  the  final  result  is  left  in  the  variable 
CURRBNT^VALUE.  Procedure  IMPCALL  copies  the  final  result 
into  its  output  variable  PINAL_RBSULT  and  then  completes. 

The  body  of  proccklure  IMPRBTURN  is  implemented  in  the 
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package  body  o£  ASYNCHR0M0U8_IHPRRCt8l_C0MPUTATI0M  in  the 
following  way: 


ptoceduze  IMPRBTURM(IHTRRMI01ATBJil8ULT  :  in 

RI8ULT_TYPB; 
BRROR.IMDICATOR  :  in 

BRROR.l  MD I CATOR.T YPB ; 
8T0P_7LA0  :  in  out 

boolean)  is 

begin 

if  not  8T0P_C0MPUTATI0N _^AO  then 

CURRBMT.VALUB  INTBRMBDIATB.RB8ULT; 

CURRBNT _^ROR_INOICATOR:  -  BRROR_lNDICATOR; 
end  if; 

if  not  8TOP^LAO  then 

8TOPJPLAO  8TOPjCONPUTATION_PLAO; 

else 

8T0P_C0MPUTATI0N_PLA0  8TOP_yLAO; 

end  if; 

end  XMPRBTURN; 


The  first  action  XMPRBTURN  takes  is  checking  the  state  of  the 
flag  variable  8TOP_COMPUTATXON_PLAO  that  is  local  to  the 
package  body.  Xf  this  flag  has  not  been  set  by  task  TIMBR, 
then  the  deadline  has  not  occurred  and  the  coeputation  task 
should  continue.  The  local  variables  CURRBMT_yALUB  and 
CURRBNT_BRROR_XNDXCATOR  are  updated  accordingly.  Xf  the  flag 
has  been  set  by  task  TXIttR,  then  the  deadline  has  occurred 
and  no  further  updates  to  CURRBMT_yALUB  and 
CURRBMT_BRROR_XNDXCATOR  are  required.  Xf  the  incoeing 
paraneter  STOP_PLAO  is  false,  then  the  XMPRBTURN  call  is 
nezely  returning  an  ieprecise  result  and  its  error  indicator. 
Parameter  8T0P_FLAG  is  set  to  the  state  of 
8T0PjC0MPUTATX0N_PLAG  so  that  the  computation  task  is 
informed  when  a  deadline  passes.  If  the  parameter  STOP.PLAG 
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Is  true,  then  the  coaputation  task  Is  si9nalllng  that  the 
coeputation  task  has  coapleted.  STOP_COMPUTATIOM_PLAG  is  set 
to  true  which  in  turn  signals  task  TIMER  to  tereinate. 

The  conplere  package  specification  and  package  body  for 
ASYNCHR0N0(/S_IMPRBCI8B_C0MPUTATI0N  can  be  found  in  Appendix 
B.  Figure  2  presents  the  asynchronous  inprecise  computation 
mechanise  in  a  graphical  manner,  using  the  symbols  outlined 
in  (5).  This  approach  to  iii4>recise  computations  has  been 
implemented  in  standard  Ada  code  and  should  compile  on  any 
validated  compiler.  However,  this  approach  requires  an 
adequate  run-time  system  to  perform  correctly.  Actual 
imprecise  coi^>utation  examples  using  this  package  are  given 
in  the  following  section. 


42 


4  lMpr«cise  Computation  Bxanples 

The  examples  in  this  section  demonstrate  how  the  9enexic 
packages  syNCHRONOUS.IMPRBCISBjCOMPUTATIOM  and 
ASYHCHROMOUS.IMPRBCISBjCOMPUTATION  are  used  to  construct 
imprecise  computation  applications. 

4.1  Monte  Carlo  Simulation 

The  Monte  Carlo  method  cam  be  used  to  siouilate  a  myriad 
of  problems.  Theoretical  examples  Include  the  solution  of 
partial  differential  equations,  the  evaluation  of  multiple 
integrals,  and  the  study  of  particle  diffusion  (91.  Practi¬ 
cal  examples  include  the  simulation  of  industrial  and 
economic  problems,  the  simulation  of  biomedical  systems,  and 
the  simulation  of  war  strategies  and  tactics  (171.  The  Monte 
Carlo  method  is  based  on  the  general  idea  of  using  sampling 
to  estimate  a  desired  result  (17J. 

The  area  of  a  circle  can  be  computed  by  the  Monte  Carlo 
method  (171.  The  idea  is  to  construct  a  square  about  the 
circle  such  that  the  square  encloses  and  Is  tangent  to  the 
circle.  Accordingly,  the  square  has  sides  equal  in  length  to 
the  diameter  of  the  circle.  Then,  random  coordinate  pairs 
are  generated  that  are  within  the  square.  Bach  coordinate 
pair  Is  tested  to  determine  if  it  is  within  the  circle.  The 
total  number  of  coordinate  pairs  generated  are  counted  and 
divided  Into  the  number  of  coordinate  pairs  that  fell  within 
the  boundary  of  the  circle.  This  fraction  Is  then  multiplied 
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■  by  the  area  of  the  square  to  yield  an  estlMte  of  thf(  area  of 
the  circle. 

P  This  Monte  Carlo  Method  of  detereining  the  area  of  a 

*  circle  has  been  used  to  create  synchronous  and  asynchronous 

ii^precise  cosq>utation  exaMples.  The  use  of  the  generic 
||  packages  SYMCHRONOUS_IHPRBCISB_COMPUTATION  and 

ASYNCHR0M0US_IMPRBC1SB_C0MPUTATI0N  is  clearly  demonstrated, 

■  along  with  the  necessary  user-%n:itten  code. 


4.1.1  Synchronous  Circle  Imprecise  Computation 

The  first  file  constructed  contains  the  data  types, 
computation  task  type,  and  procedure  declarations  that  will 
be  used  to  instantiate  SYNCHROMOCrS.INPRBCXSB.COMPUTATZON. 
Because  this  file  contains  related  types  and  procedures,  it 
is  fashioned  as  a  package  specification.  Its  package  body 
will  contain  the  task  and  procedure  bodies.  The  package 
specification  for  SYNCHRONOUS_CIRCLB_COHPUTATION  includes  the 
following  declarations: 


I  subtype  RBSULT.TYPB  is  float; 

subtype  BRROR_TYPB  is  integer; 

%  type  ZNPUT_TYPB  is  record 

LOOPS.TOjCONPLBTB  :  integer; 

A  RADIUS  :  float; 

■  end  record; 

ftask  type  TBST_TASK  is 

entry  INITIALIZE (INPUT  :  in  INPUT.TYPE); 
entry  COMPUTE (COHPUT ATI ON.COMPLETB  :out  boolean); 
entry  HANDLER (1  ..  2 ) (LAST_RBSULT: in  RBSULT^TYPE; 
m  LAST.BRROR  : in  BRROR.TYPB); 


entry  STOP; 
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end  TBST.TASK; 

type  TBST_PTR  is  access  TBST_TASK; 

procedure  INITIALIZB(THB_TASK  :  in  TBST.PTR; 

INPUT  :  in  IMPUT_TYPB); 

procedure  COMPUTB(THB_TASK  :  in  TBST.PTR; 

COMPUTATIOM_COMPLBTB  :out  boolean); 

procedure  HAMDLB(THB_TASK  :in  TBST_PTR; 

HAMDLER.NUMBBR  :in  integer; 

LAST.VALUB  : in  RBSULT.TYPB; 

LAST_BRROR_I HDI GATOR : i n  BRROR_TYPB ) ; 

procedure  STOP ( THBJTASK  :  in  TBST_PTR); 

The  result  of  the  computation  will  be  a  floating  point  value 
representing  an  estimate  of  the  area  of  a  circle/  so 
RESULT_TYPB  is  made  a  subtype  of  float.  To  monitor  the 
precision  of  the  imprecise  result/  a  counter  will  count  the 
number  of  random  coordinate  pairs  generatcsd.  Therefore/ 
BRRORJTYPB  is  created  as  a  subtype  of  integer.  At  initiali¬ 
zation/  the  computation  task  will  need  two  pieces  of  informa¬ 
tion.  Represented  by  the  elements  in  type  IMPUTJTYPE/  this 
information  is  the  number  of  random  coordinate  pairs  to 
generate  before  a  precise  result  is  achieved/  and  the  radius 
of  the  circle.  The  task  type  TEST_TASK  is  the  computation 
task.  It  includes  the  necessary  entry  points  to  initialize 
the  task/  cause  one  iteration,  handle  an  imprecise  result, 
and  stop  the  task.  Mote  that  entry  HANDLER  has  been  imple¬ 
mented  as  a  family  of  entries.  The  type  TBST.P'^R  is  a 
pointer  to  task  type  TBST.TASK.  The  four  procedures 
INITIALIZE,  COMPUTE,  HANDLE,  and  STOP  are  required  to  allow 
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the  inpreclse  computation  mechanism,  which  has  no  prior 
knowledge  of  the  computation  task  type,  to  call  specific 
entry  points  within  the  computation  task.  Vhen  this  package 
specification  Is  compiled.  It  is  entered  into  the  user's  Ada 
library  where  it  can  be  further  referenced. 

Mow  that  the  required  data  types,  task  type,  and 
procedures  have  been  declared,  an  Instantiation  of  the 
generic  package  SYNCHRONOUS_IMPRBCISE_COMPUTATIOM  can  be 
made.  The  declarations  in  the  package  specification  of 
syMCHROMOUS_ClRCLE_COMPUTATIOM  will  be  used  to  create  the 
package  SYNCHROMOUS_CIRCLB_IMPRECISB_COMPUTATION  in  the 
following  manner: 


wi th  S YMCHROMOUS.CI RCLBjCOMPUTATI ON ; 
use  SYNCHRONOUS_CIRCLB.COMPUTATION; 
wi th  S YNCHROMOUS.I MPRBCI SBjCOMPUTATI ON ; 
package  SYNCHROHOUS_CIRCLB_IMPRBCISB_COMPUTATIOM 
new  SYNCHRONOUS  IMPRECISE  COMPUTATION 


Is 


(COMPUTATION  «> 

COMPUTATION_PTR  «> 

RESULT_TYPE  »> 

ERROR_INDICATOR_TYPB  *> 
INPUTJTYPE  ■> 

INITlj^IZB  -> 

COMPUTE  -> 

HANDLE  >> 

STOP  »> 


TEST_TASK, 

TBST_PTR, 

RESULT_TYPE, 

BRROR_TYPE, 

INPUT_TYPB, 

INITI^IZE, 

COMPUTE, 

HANDLE, 

STOP ) ; 


Vhen  this  file  is  compiled,  a  new  synchronous  iioprecise 
computation  package  is  created  that  Includes  the  declarations 
in  SYNCHR0N0US_CIRCLE_C0NPUTATI0N'8  package  specification. 

The  next  file  to  compose  and  compile  Is  the  package  body. 

The  new  Imprecise  computation  package  Is  Instantiated  before 
the  computation  package  body  Is  compiled  for  a  crucial 
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reason. 

The  imprecise  computation  mechanism  employs  a  circular 
calling  pattern.  Procedure  IHPCALL  calls  procedures  that 
call  entry  points  of  the  computation  task.  In  the  meantime, 
the  computation  task  is  calling  procedure  IMPRETURN  with 
imprecise  results  and  error  indicators.  When  the  new  package 
is  instantiated  after  the  declarations  are  made  in  the 
computation  package  specification,  the  new  IHPCALL  is 
supplied  with  the  procedure  declarations  it  needs  to  get  its 
job  done.  The  impleowntation,  or  body  of  these  procedures  is 
of  no  consequence  to  IHPCALL.  After  instantiation,  a  valid 
IHPRETURN  exists  in  the  new  imprecise  computation  package. 

At  this  point,  the  computation  task  body  which  relies  on 
IHPRETURN  can  be  coded.  In  this  way,  a  single  package  can 
house  the  synchronous  imprecise  computation  mechanism,  even 
though  circular  calling  exists. 

The  package  body  for  STNCHRONOUS_CIRCLE_COHPUTATION 
contains  the  following  procedure  bodies; 


procedure  INITIALIZE(THE_TASK  :  in  TEST.PTR; 

INPUT  :  in  INPUT_TyPE)  is 

begin 

THE_TASK . INI TI ALI ZS ( INPUT ) ; 
end  INITIALIZE; 

procedure  COHPUTE ( THE JTASK  :  in  TEST_PTR; 

COHPUTATION_COHPLETE  :  out 

boolean)  is 

begin 

THE_TASK .  COHPUTE  ( COHPUTATION_COHPLETE )  ,* 
end  COHPUTE; 

procedure  HANDLE ( THE_T ASK  :  in  TEST_PTR; 

HANDLER.NUHBER  :  in  integer; 
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LAST_VALUB  ;  In  RBSULT_TYPB; 

LAST.BRROR_INDICATOR  :  in  BRROR^TYPB)  is 

begin 

THB_TASK . HANDLBR ( HANDLBR_MUMBBR ) 

(LAST.VALUB, 

LAST_BRROR_IHDICATOR) ; 

end  HANDLB; 

procedure  STOP ( THB_TASK  :  in  TBST.PTR)  is 
begin 

THB_TASK.STOP; 
end  STOP; 


These  procedures  call  their  respective  entry  points  in  the 
computation  task.  Although  the  procedure  names  and  the  entry 
points  have  exact  or  similar  names,  the  names  are  independent 
of  the  synchronous  imprecise  computation  mechanism.  The  only 
names  it  needs  are  the  names  used  to  instantiate 
SYMCHRONOUS_CIRCLB_IHPRECISBjCOMPUTATIOM.  The  task  body  for 
task  type  TBSTJTASK  has  the  following  structure: 


task  body  TBSTJTASK  is 

...  local  variable  declarations  ... 


begin 

accept  IHITIALIZEC INPUT  :  in  INPUT.TYPB)  do 
...  initialize  variables  with  input  ... 
end  INITIALIZE; 
loop 

select 

accept  COMPUTE (COHPUT ATI ON_COHPLBTB  :  out 

boolean)  do 

...  generate  random  coord  pairs  ... 

. . .  check  circle  boundary  . . . 

. . .  compute  area  . . . 

. . .  check  if  precise, 

set  COMPUTATION.COMPLETB  . . . 

. . .  IMPRBTURN  . . . 
end  COMPUTE; 
or 

accept  HANDLER (1)(LAST_RESULT  :  in 

RESULT_TYPE; 
LAST  ERROR  :  in 
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or 


BRROR_TYPE)  do 

. . .  handler  11  code  . . . 

...  IMPRETURN  ... 
end  HAMOLBR; 

accept  HAIIDLER(2)(LAST_RBSULT  :  In 

RBSULT_TYPB; 
LAST.ERROR  :  in 

BRROR.TYPE)  do 

. . .  handler  12  code  . . . 

. . .  IMPRETURN  . . . 
end  HANDLER; 


or 


accept  STOP  do 

FINISHED  true; 
end  STOP; 
end  select; 
exit  when  FINISHED; 
end  loop; 
end  TEST_TASK; 


After  initialization,  the  task  continuously  loops  through  a 
select  statement.  The  select  statement  causes  the  task  to 
wait  for  a  call  to  any  one  of  the  entry  points.  The  COMPUTE 
entry  point  contains  the  code  that  implements  the  random 
sampling  of  the  Monte  Carlo  method  and  the  area  calculation 
code.  The  HANDLER  entry  family  contains  the  code  necessary 
to  further  manipulate  the  final  imprecise  result.  The  loop 
is  exited  by  a  rendezvous  with  the  STOP  entry  point.  No 
other  entities  are  required  in  the  computation  package  body. 
After  this  package  body  is  compiled  and  subsequently  entered 
into  the  user's  Ada  library,  a  self-contained,  operational 
synchronous  imprecise  computation  package  exists  and  can  be 
used.  The  following  VAX  Ada  program  exercises  the  synchro¬ 
nous  package: 


with  SYNCHR0N0U8_CIRCLB_C0MPUTATI0N ; 
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use  SYNCHRONOUS_CIRCLB.COHPUTATION; 

with  SyNCHROMOUS_CI RCLE_I MPRBCI SB.COMPUTATI ON ; 

US  e  SYNCHRONOUS  _C I RCLB_I HPRBC I S B_COMPUT AT ION; 
with  CALENDAR;  ~  use  CALENDAR; 

with  TBXT_IO;  use  TBXT_IO; 

with  PLOAT_TEXT_IO;  use  PLOAT_TEXT_IO; 

with  INTEGER_TEXT_IO;  use  INTEGBR_TEXT_IO; 

procedure  SYNCHRONOUS_CIRCLB_TBST  is 


MY_TASK_PTR 
DEAD 
RESULT 
COMP_TIME 
MY  INPUT 


TEST_PTR  :»  new  TEST_TASK; 

CALENDAR. TIME; 

RESULT_TYPE; 

float; 

SYNCHROMOUS_CIRCLE_COMPUTATIOM . 
INPUT_TYPB; 


begin 

put ("Enter  the  circle  radius  b> 
ge t ( M Y_I NPUT . R AO I US ) ; 

put ("Enter  number  of  iterations  to  complete  «>"); 

get ( MY_INPUT . LOOPS_TO_COMPLBTE ) ; 

put ("Enter  computation  duration  in  seconds  »>"); 

got(COMP_TIME); 

put_line( "Synchronous  CIRCLE  TEST  starting..."); 
DEAD  ;»  CALENDAR. CLOCK  ♦  DURATION ( COMP_TIMB )  ; 
SYNCHRONOUS  Cl RCLB.I MPRBCI SB  COMPUTATION. 
impcallTmy  TASK_PTR, 

DEAD, 

MY_INPUT, 

RESULT ) ; 

put ("TEST  ending...  RESULT  ->  "); 
put (RESULT,  EXP  ->  0,  APT  ->  2); 
new_line; 

end  SYNCHRONOUS_CIRCLB_TBST; 


Once  the  computation  package  is  built  and  compiled  correctly, 
using  it  is  quite  simple.  After  the  input  parameters  are 
determined,  the  imprecise  computation  is  run  by  merely 
invoking  the  IMPCALL  procedure  in  the  newly  instantiated 
SYNCHRONOUS.CIRCXB.IMPRECISB.COMPUTATION  package.  The 
complete  file  listings  for  this  example  are  located  In 
Appendix  C. 
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4.1.2  Asynchronous  Circle  Imprecise  Computation 

A  similar  sequence  of  files  is  used  to  build  an  asyn¬ 
chronous  imprecise  computation  application  because  the 
asynchronous  approach  also  relies  on  a  circular  calling 
oMchanism.  The  first  file  constructed  contains  data  types / 
task  type,  and  procedure  declarations  required  for  instantia¬ 
tion  of  generic  package  ASyNCHRONOUS_IMPRBCISB_COHPUTATION . 
These  declarations  are  located  in  the  package  specification 
for  A8YNCHR0M0US_CIRCLB_C0MPUTATI0M  in  the  following  format: 

subtype  RBSULT_TyPB  is  float; 

subtype  BRROR_TyPB  is  integer; 

type  INPUT jryPB  is  record 

LOOPS.TO  COMPLBTB  :  integer; 

RADIUS  :  float; 

end  record; 

task  type  TEST JT ASK  is 
pragma  PRIORITy(O); 

entry  START.CONPUTATI ON (INPUT  :  in  INPUT.TTPB); 

end  TBST.TASK; 

type  TEST  .PTR  is  access  TBST.TASK; 

procedure  START_COMPUTATION(THB_TASK  ;ln  TBST_PTR; 

INPUT  :in  INPUT_TyPB); 

procedure  HANDLE (LAST.VALUB  :  in  out 

RESULT  TYPE; 

LAST_BRROR_INDICATOR  :  in  out 

BRROR_TyPB); 

The  subtypes  RBSULT.TYPB,  BRROR.TYPB,  and  INPUT.TYPB  are  the 
same  as  in  the  synchronous  example.  However,  the  task  type 
TBSTJTASK  is  quite  different.  The  task  must  contain  the 
priority  pragma  statement  with  a  priority  lower  than  that  of 
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th«  TIMER  task  In  ASYMCHROMOUS.IMPRBCISBjCOMPUTATIOM.  Task 
type  TBST_TA8K  contains  a  single  entry  point  %fhere  the  task 
Is  Initialized  and  then  turned  loose.  The  type  TEST _pTR 
reaalns  as  an  access  type  pointing  to  TBSTJTASK.  The 
procedure  STARTjCOMPUTATION  Is  required  to  allow  the  asyn¬ 
chronous  lapreclse  cooqiutatlon  aechanlsBi,  i#hlch  has  no 
knowledge  of  the  Internal  structure  of  the  computation  task, 
to  Indirectly  call  the  STARTjCOMPUTATION  entry  point.  The 
procedure  HANDLE  la  not  affiliated  with  the  computation  task 
as  It  Is  In  the  synchronous  version,  but  accomplishes  the 
same  function  of  manipulating  the  final  Imprecise  result. 

The  compiled  ASYNCHRONOUS.CIRCLB.COMPUTATION  package  specifi¬ 
cation  la  entered  Into  the  user's  Ada  library  where  It  can  be 
further  referenced  by  the  application. 

Once  the  required  data  types,  task  type,  and  procedures 
have  been  declared,  a  new  package  can  be  created  by  Instanti¬ 
ating  the  generic  package  ASYNCHRON0US_IMPRECISE_C0HPUTAT10N. 
This  Is  accomplished  In  the  following  file: 


with  AS  YNCHRONOUS_C I RCLE_C0MPUT AT I ON ; 
use  AS YNCHRONOUS.CI RCLBjCOMPUTATI ON } 
with  ASYNCHRONOUS _I MPREC I SB.COMPUT AT I ON ; 
package  ASYNCHRONOUS_CIRCLE_IMPRECISB_COMPUTATION  Is 
new  AS YNCHRONOUS.I MPRECI SE_COMPUTATI ON 
(COMPUTATION  ■>  TEST_TASK, 

COMPUTATIOM_PTR  «>  TBST_PTR, 

RESULT_TYPE  ->  RBSnLT_TYPE, 

ERROR  INDICATOR_TYPE  ■>  ERROR_TYPE, 

INPUT_TYPB  »>  INPUT_TYPE, 

8TART_C0MPUTATI0N  =>  START_COMPUTATION, 

HANDLE  «>  HANDLE); 


Vhen  this  file  Is  compiled,  a  new  asynchronous  Imprecise 
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computation  package  is  created.  This  new  package  contains 
the  declarations  from  the  package  specification  of 
ASYNCHRONOUSjCIRCLBjCOMPUTATlOM  substituted  in  for  the 
generic  parameters.  The  next  step  is  to  impleswnt  the  body 
of  the  computation  package. 

The  package  body  of  ASYNCHRONOUS^CIRCLB.COMPUTATION 
contains  the  following  procedure  bodies: 


procedure  8TART_COMPUTATIOM(THB_TASK  :  in  TBST_PTR; 

INPUT  :  in  INPUT.TYPB)  is 

begin 

THB_TASK . START_COMPUTATI ON ( INPUT ) ; 
end  START_COMPUTATION; 


procedure  HANDLE ( LAST_VALUB 

LAST^BRROR.I ND I GATOR 


begin 


in  out 

RBSULT_TYPB; 
in  out 

BRROR  TYPE)  is 


. . .  handler  routine  . . . 
end  HANDLE; 

Procedure  START jCOMPUTATION  merely  calls  THE_TASK  at  the 
START jCOMPUTATION  entry  point.  During  the  rendezvous,  the 
initialization  INPUT  is  passed  to  the  compute  task.  Pro¬ 
cedure  HANDLE  is  a  standalone  procedure  that  manipulates  the 
final  imprecise  result.  Also  included  in  the  computation 
package  body  is  the  body  of  task  type  TESTJTASK.  It  has  the 
following  structure: 


task  body  TBST.TASK  is 

...  local  variable  declarations  ... 


begin 

accept  START_COMPUTATI ON (INPUT  : in  INPUT_TYPE)  do 
...  initialize  local  variables  ... 
end  START.COMPUTATION; 
delay  DURATION 'SMALL; 
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loop 

...  generate  random  coordinate  pairs  ... 

. . .  test  boundary  of  circle  ... 

. . .  compute  area  . . . 

...  check  If  precise,  set  FINISHED  ... 

...  IMPRBTURH  ... 
exit  when  FINISHED; 
end  loop; 
end  TEST_TASK; 

The  purpose  of  the  delay  statement  with  the  minimal  amount  of 
delay  Is  to  allow  the  TIMER  task  to  regain  Immediate  control 
of  the  processor  after  the  rendezvous  with  TEST_TASK.  The 
delay  statement  causes  TEST_TASK  to  be  blocked  and  allovfs  the 
higher  priority  TIMER  task  to  execute.  After  the  TIMER  task 
determines  Its  delay  amount  and  suspends  Itself,  the  task 
TEST_TASK  regains  control  of  the  processor  and  proceeds  with 
the  computation.  The  TBSTJTASK  loop  Is  not  exited  until  It 
achieves  a  precise  result  or  Is  signalled  to  exit  via  the 
IMPRBTURN  call.  No  Other  entitles  are  required  In  the 
computation  package  body.  After  this  package  Is  compiled  and 
entered  Into  the  user's  library,  a  fully  operational  asyn¬ 
chronous  Imprecise  computation  mechanism  Is  available  by 
referencing  ASYNCHRONOUS_CIRCLB_IMPRBCISB_COMPUTATION.  This 
new  package  Is  used  in  the  following  VAX  Ada  procedure: 


with  ASYNCHRONOUS.CIRCLBjCOMPUTATION; 
use  AS YNCHRONOUS_CI RCLB.COMPUTATI ON ; 
with  ASYNCHRONOUS  CIRCLB_IMPRBCISB_COMPUTATION; 
use  ASYNCHRONOUS  CIRCLB_IMPRBCISB_COMPUTATION; 
with  CALENDAR;  use  CALENDAR; 

with  TEXT_IO;  use  TEXT_IO; 

with  PLOAT_TEXT_IO;  use  FLOAT_TEXT_IO; 

with  INTBOER_TEXT_IO;  use  INTBGER_TEXT_IO; 

procedure  ASYNCHRONOUS_CIRCLB_TBST  Is 
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pragma  TIHBJ3LICB(0.01); 


MY_TASK_PTR 

DBAO 

RBSULT 

COMPJTIMB 

MY_INPUT 


TBST_PTR  new  TBST_TASK; 

CALBMDAR.TIMB; 

RBSULT__TyPB; 

float; 

ASYNCHRONOUS.CIRCLB.COMPUTATI ON . 
INPUT_TYPB; 


begin 

put("Bnter  the  circle  radius  ■>  ”); 
get ( MY_IMPUT . RADIUS ) ; 

putCBnter  number  of  Iterations  to  complete  «>"); 
get ( MY_IMPUT . LOOPS  JTOjCOMPLBTB ) ; 
put(''Bnter  computation  duration  in  seconds  «>  "); 
get(COHP_TIMB); 

put__llne( "Asynchronous  CIRCLE  TEST  starting..."); 
DEAD  :*  CALENDAR. CLOCK  DURATION(COMP_TIHB) ; 

AS  YNCHRONOUS JCI RCLB.IMPRBCI SB_COMPUTATI ON . 

I MPCALL ( MY_TASK_PTR , 

DEAD, 

MY  INPUT, 

RESULT); 

put ("CIRCLE  TEST  ending. . .CIRCLE  AREA  RBSULT»>"); 
put (RESULT,  EXP  «>  0,  APT  »>  2);  new_line; 
end  ASYNCHRONOUS  CIRCLB.TBST; 


Like  its  synchronous  version,  the  asynchronous  imprecise 


computation  package  is  quite  easy  to  use.  Once  compiled 
correctly,  it  can  be  accessed  by  simply  invoking  IMPCALL  with 
the  necessary  parameters.  A  complete  listing  of  the  example 
files  for  asynchronously  computing  the  area  of  a  circle  can 


be  found  in  Appendix  D. 


4.2  Iterative  Numerical  Methods 

Iterative  numerical  methods  involve  the  repeated 
application  of  an  operator.  These  methods  include  Nev^ton's 
method  (nonlinear  equations),  the  Jacobi  method  (linear 
equations),  and  the  Newton  divided -difference  method  (Infi¬ 
nite  series  approximation)  among  others  [15,161.  This 
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example  demonstrates  another  use  of  the  synchronous  and 
asynchronous  approaches  In  Implementing  an  imprecise  computa¬ 
tion  application.  SyNCHROMOUS_XMPRBCISB_COMPUTATIOM  and 
ASYNCHROMOUS^IMPRBCISBjCOMPUTATIOM  are  generic  packages  used 
to  implement  a  synchronous  and  an  asynchronous  linear  system 
of  equations  solver  that  utilizes  the  Jacobi  method. 


4.2.1  Synchronous  Jacobi  Imprecise  Computation 

The  sequence  of  file  generation  and  compilation  is 
identical  to  the  previous  example.  The  first  file  generated 
is  the  package  specification.  This  file  contains  the  data 
types /  task  type,  and  procedure  declarations  that  will  be 
uscMi  to  instantiate  a  custom  synchronous  imprecise  computa¬ 
tion  package.  The  following  declarations  are  used  for  the 
Jacobi  method: 


N  :  constant  integer  :=  3; 

type  RBSULT_TYPB  is  arrayd  ..  N)  of  float; 
subtype  BRRORJTYPB  is  integer; 

type  COBPFICIBNT_TYPB  is  arrayd  ..  N,  1  ..  N)  of  float; 

type  INPUT_TYPE  is  record 

COBFPICIBHTS  :  COEFFICIBNT.TYPB; 

RIGHT  HAMD_SIDE  :  RBSULT_TYPB; 

XOLD  :  RESULTJTYPB; 

TOL  :  float; 

end  record; 

task  type  TESTJTASK  is 

entry  INITIALIZE (INPUT  :  in  INPUT_TYPE); 

entry  COMPUTE (COMPUT ATI ON.COHPLETE  tout  boolean); 

entry  HANDLERd  ..  2 )  (LAST.RESULT:  in  RESULT_TYPE; 

LAST  ERROR  tin  BRROR.TYPB); 


entry  STOP; 


end  TBST.TASK; 

type  TBSTJPTR  is  access  TBST_TASK; 

procedure  INITIALIZB(THB_TASK  :  in  TBST  PTR; 

INPUT  :  in  INPUT_TYPB); 

procedure  COMPUTBCTHBJTASK  :  in  TBST_PTR; 

COMPUTATIOM.COMPLBTB  :  out  boolean); 

procedure  HANDLE (THB_T ASK  :  in  TBST_PTR; 

HANDLBRJHUMBBR  :  in  integer; 

LAST_VALUB  :  in  RESULT_TYPE; 

LASTJBRROR_INDICATOR  :  in  BRROR.TYPE); 

procedure  STOP ( THB_T ASK  :  in  TBST.PTR); 

The  integer  constant  N  represents  the  number  of  equations  in 
the  linear  system.  Likewise,  N  also  represents  the  number  of 
coefficients  in  each  equation.  The  type  RBSULTJTYPE  indi¬ 
cates  that  a  solution  vector  with  N  floating  point  components 
will  be  the  result  of  the  computation.  The  subtype 
ERRORJTYPE  is  defined  as  an  integer,  for  the  error  will  be 
represented  by  an  integer  counter  indicating  the  number  of 
iterations  accomplished.  The  type  COBFPICIBNT_TYPB  defines 
an  N  by  N  matrix  of  floating  point  values.  This  type  is  not 
directly  used  in  Instantiation,  but  is  used  in  the  definition 
of  the  input  to  the  computation.  Type  INPUTJTYPB  is  a  record 
type  containing  4  fields.  The  field  COEFFICIENTS  is  an  N  by 
N  matrix  containing  the  coefficients  of  the  equations  in  the 
linear  system.  The  right  hand  side  of  these  equations  is 
stored  in  the  field  RIGHT_HAND_SIDB.  The  field  XOLD  contains 
an  initial  guess  at  the  solution  vector.  This  gives  the 
Jacobi  method  a  place  to  start.  The  field  TOL  is  the 
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tolerance  used  to  determine  whether  a  new  solution  vector, 
when  corqpared  to  the  previous  one,  can  be  considered  a 
precise  result.  The  task  type  TB8T_TASK  contains  the 
appropriate  entry  calls  required  by  the  synchronous  imprecise 
computation  mechanism  to  initialize  the  task,  cause  an 
iteration  of  the  computation,  handle  an  imprecise  result,  and 
stop  the  task.  A  pointer  type  to  this  task  type  is  defined 
as  type  TBST_PTR.  Finally,  the  procedures  INITIALIZE, 
COMPUTE,  HANDLE,  and  STOP  are  declared  so  that  the  synchro¬ 
nous  imprecise  coaqtutation  mechanism,  when  instantiated  with 
these  declarations,  can  call  the  entry  points  of  a  task. 

These  procedures  are  necessary  because  the  synchronous 
mechanism  has  no  prior  knowledge  of  the  task  TBSTJTASK  or  its 
structure.  Cnee  this  package  specification  is  compiled,  it 
is  entered  into  the  user's  Ada  library  where  it  can  be 
further  referenced  by  the  application. 

With  the  data  types,  task  type,  and  procedures  declared 
in  the  package  specification,  an  instantiation  of  the  generic 
package  SYNCHRONOUS.IMPRECISBjCOMPUTATION  can  be  made.  The 
declarations  in  the  SYNCHRONOUS_JACOBI_COMPUTATION  package 
specification  are  used  to  create  the  new  package 
SYNCHRONOUS_JACOBI_INPRBCISB_CONPUTATION  in  the  following 
way: 


with  S YNCHR0N0U8_JAC0BI_C0HPUTATI ON ; 
use  8YNCHR0N0U8  JACOBI.COMPUTATION; 
with  8YNCHRONOUS_IMPRBCI8BjCOMPUTATION; 
package  8YNCHR0N0U8_JAC0BI  IMPRBCISBjCOMPUTATION  Is 
new  8YNCHR0N0U8  lMPRBCr8B  COMPUTATION 
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(COMPUTATION  »>  TEST_TASK, 

COMPUTATION_PTR  ■>  TEST_PTR, 

RESULT_TYPE  ■>  RESULT_TYPB, 

BRROR_INDICATOR_TYPB  «>  ERROR_TYPE, 

INPUT_TYPB  »>  INPUT_TYPE, 

INITIALIZE  ->  INITIALIZE, 

COMPUTE  «>  COMPUTE, 

HANDLE  a>  HANDLE, 

STOP  ■>  STOP); 


After  this  file  is  compiled,  a  new  synchronous  imprecise 
computation  package  exists  in  the  user's  library.  This  new 
package  contains  the  same  mechanism,  but  with  the  new 
declarations  substituted  in  for  the  generic  parameters.  The 
next  file  defines  the  bodies  for  the  task  type  and  the 
procedures  declared  in  the  package  specification. 

The  package  body  of  SYNCHRONOUS_JACOBI  jCOMPUTATION 
contains  the  implementation  details  of  the  task  type  and 
procedure  bodies.  The  procedure  bodies  are  implemented  in 
the  following  way: 


procedure  INITIALIZE (THE.TASK  :  in  TEST.PTR; 

INPUT  :  in  INPUT_TYPE)  is 

begin 

THE_TASK . INITl ALI ZE ( INPUT ) ; 
end  INITIALIZE; 

procedure  COMPUTE ( THE JT ASK  :  in  TEST_PTR; 

COMPUTATION.COMPLETB  :  out  boolean)  is 

begin 

THB_TASK . COMPUTE ( COMPUTATI ONjCOMPLETE ) ; 
end  COMPUTE; 

procedure  HANDLE (THB_TASK  :in  TEST_PTR; 

HANDLER .NUMBER  :in  integer; 

LAST.VALUB  : in  RBSULT.TYPE; 

LAST_ERROR.IHDICATOR;in  ERROR.TYPE)  is 

begin 

THB.TASK . HANDLER ( HANDLER.NUHBBR ) 

( LAST.VALUE,  LAST.BRROR.INDICATOR ) ; 
end  HANDLE; 


59 


procedure  STOP ( THB_TA8K  :  In  TBST.PTR)  is 
begin 

THB.T ASK. STOP; 
end  STOP; 


These  procedures  call  their  respective  entry  points  in  the 
Jacobi  computation  task.  The  procedures  and  entry  points  can 
have  any  names.  The  only  requirement  is  that  the  procedures 
used  to  instantiate  the  new  synchronous  imprecise  computation 
package  call  the  appropriate  entry  point  in  the  Jacobi 
computation  task.  The  task  body  for  task  type  TBST_TASK  has 
the  following  structure: 


task  body  TEST.TASK  is 

...  local  variable  declarations  ... 
begin 

accept  INITIALIZE (INPUT  :  in  INPUT.TYPB)  do 

...  initialize  local  variables  with  input  ... 
...  normalize  coefficient  matrix  ... 
end  INITIALIZE; 
loop 

select 

accept  COMPUTE (COMPUT ATI ON.COMPLBTE  : 

out  boolean)  do 

. . .  coiiq>ute  new  solution  vector 
using  method  in  (15,16]  ... 

...  find  absolute  difference 

between  old  and  new  elements . . 

. . .  let  present  estimate  be 
improved  estimate  ... 

. . .  report  current  result 
with  IMPRBTURN  . . . 
end  COMPUTE; 
or 

accept  HANDLBR(l) 

(LAST_RBSULT  :  in  RBSULT_TYPB; 
LAST^BRROR  :  in  BRROR.TYPB)  do 
. . .  handler  11  code  . . . 

. . .  IMPRBTURN  . . . 
end  HANDLER; 
or 

accept  HANDLBR(2) 


(LAST_RB8ULT  :  In  RESULT  TYPE; 
LAST_^ROR  :  in  ERROR.TYPE)  do 
. . .  handler  12  code  . . . 

...  IMPRETURN  ... 
end  HANDLER; 
or 

accept  STOP  do 

FINISHED  :>  true; 
end  STOP; 
end  select; 
exit  when  FINISHED; 
end  loop; 
end  TBST_TASK; 


During  initialization,  the  values  of  the  input  record  are 
copied  to  local  variables.  The  input  record  fields  cannot  be 
used  directly  in  the  cosqputation  task  because  their  scope  is 
limited  to  the  INITIALIZE  rendezvous.  The  coefficient  matrix 
is  then  normalized  and  the  rendezvous  is  complete.  The  task 
then  enters  a  loop  that  contains  a  select  and  an  exit 
statement.  The  task  waits  for  an  entry  call,  performs  the 
operation  in  the  rendezvous,  and  then  checks  if  it  should 
exit  the  loop.  The  COMPUTE  entry  point  contains  the  imple¬ 
mentation  of  the  Jacobi  method  as  specified  in  [15,16].  The 
HANDLER  entry  family  contains  the  code  necessary  to  further 
manipulate  the  final  imprecise  result.  The  STOP  entry  point 
sets  the  flag  that  triggers  the  loop  exit.  No  other  entities 
are  required  in  the  SYNCHRONOUS_JACOBI_COHPUTATION  package 
body.  After  this  package  body  is  compiled  and  entered  into 
the  user's  Ada  library,  a  self-contained  synchronous  impre¬ 
cise  Jacobi  computation  mechanism  exists.  Real-time  programs 
in  need  of  an  imprecise  Jacobi  computation  package  can  call 
SYNCHR0N0US_JAC0B1_IMPRECISB_C0MPUTAT10N  in  the  following 
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Wi th  S YNCHROHOUS_JACOBI_COMPUTATI ON ; 

usa  SYNCHRONOUS _JACOBIjCOHPUTATION; 

with  S YNCHR0N0U8_J ACOBI _I MPRBCI SB.COHPUTATI ON ; 

usa  SYNCHRONOUS  J ACOB I _IMPRBC I SB  COMPUTATION; 

with  CALENDAR;  usa  CALENDAR; 

with  TBXT_IO;  usa  TBXT_IO; 

with  PLOAT_TEXT_IO;  usa  PLOAT_TBXT_IO; 

with  1NTBGBR_TBXT_I0;  usa  INTBGBR_TBXT_IO 

procadura  SYNCHRONOUS_JACOBI_TBST  is 

MY_TASK_PTR  :  TEST_PTR  now  TBST_TASK; 

DEAD  :  CALENDAR. TIME; 

RESULT  :  RBSULT^TYPB; 

COMP_TIME  :  PLOAT; 

INPUT  :  INPUT_TYPB; 

bagin 

fox  INDEX  in  1  . .  N  loop 

put_lina( "Bntar  tha  coafficiants  and  "  i 

"right  hand  sida  for  aquation  "  & 
intagar ' inaga{ INDEX) ) ; 
tor  NUM  COBPP  in  1  . .  N  loop 

gat ( INPUT .COBPPICIBNTS ( INDEX, NUN.COBPP ) ) 
and  loop; 

gat ( INPUT. RIGHT_HAMD_SIDB( INDEX) ) ; 
and  loop; 

for  INDEX  in  1  ..  N  loop 

INPUT.XOLD(INDBX)  :«  0.0; 
and  loop; 

put("Bntar  tolarance  factor  «>  "); 
gat(INPUT.TOL); 

put("Bntar  tha  conputation  duration^secs . )  >>  ") 
gat(COMP_TIMB); 

put_lina( "Synchronous  Jacobi  test  starting..."); 
DEAD  CALENDAR. CLOCK  *  DURATION (COMP  TIME); 

SYNCHRONOUS_JACOBI_IMPRBCI SB_COMPUTATION . 

I MPCALL ( M Y_TASK_PTR , 

1, 

DEAD, 

INPUT, 

RESULT); 

put_lino( "Jacobi  TEST  anding...  "); 
for  INDEX  ini  . .  N  loop 

put("X");  put (INDEX, WIDTH  »>  1);  put("  »>  ") 
put  (RESULT  (INDEX),  EXP  -*>0); 
new_lina; 
and  loop; 

end  SYNCHRONOUS.JACOBIJTEST; 
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A£ter  the  synchronous  Imprecise  Jacobi  coaputatlon  sMchanlsa 
Is  built,  using  it  is  quite  staple.  After  the  input  vari¬ 
ables  are  deterained,  a  single  IMPCALL  runs  the  entire 
iaprecise  coaputation.  The  coaplete  file  listings  for  this 
exasqple.  Including  the  iapleaentation  of  the  Jacobi  aethod, 
are  located  in  Appendix  B. 


4.2.2  Asynchronous  Jacobi  Iaprecise  Coaputation 

The  sequence  of  files  Is  again  the  saae  because  of  the 
circular  calling  aechanisa  eaployed.  The  package  specifi¬ 
cation  for  the  asynchronous  coaputation  looks  like  this: 


N  :  constant  integer  :>  3; 

type  RBSULT.TYPB  is  array  (1  ..  N)  of  float; 
subtype  ERROR^TYPB  is  integer; 

type  COBFFICIBNT_TYPB  is  arrayd  ..  N,  1  ..  N)  of  float; 

type  INPUT_TYPB  is  record 

COEFFICIENTS  :  COEFPICIENT.TYPE; 

RIGHT_HAND_SIDE  :  RBSULT.TYPB; 

XOLD  :  RESULTJTYPE; 

TOL  :  float; 

end  record; 

task  type  TEST JT ASK  is 
pragma  PRIORITY(O); 

entry  START  COMPUTATION! INPUT  ;  in  INPUT_TYPE); 
end  TEST.TASK; 

type  TEST_PTR  is  access  TEST_TASK; 

procedure  START_CONPUTATION(THB_TASK  ;  in  TEST_PTR; 

INPUT  :  in  INPUT_TYPE); 

procedure  HANDLE (LAST_VALUE  :  in  out 

RESULT_TYPE; 

LAST_ERROR_INDICATOR  :  in  out 

BRROR_TYPE); 
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The  integer  constant  N  represents  the  nueber  of  equations  in 
the  linear  system.  The  type  RB8ULT_TyPB  represents  the  fore 
of  the  final  result  %fhich  will  be  a  solution  vector  with  N 
elements.  Type  BRRORJTYPB  will  again  be  an  integer  count  of 
the  number  of  iterations.  The  type  COBFPICIBMT_TYPB  will  not 
be  used  directly  for  instantiation,  but  represents  an  N  by  N 
matrix  of  coefficients.  The  type  INPUT_TYPB  is  the  same  as 
the  synchronous  input.  The  coefficient  matrix  C0BPPICIBNT8, 
the  values  to  the  right  of  the  equal  operator 
RIGHT_HAM0_S1DB,  the  initial  solution  guess  XOLD,  and  the 
tolerance  TOL  are  passed  to  the  computation  task  at  initiali¬ 
zation.  The  specification  of  task  type  TBST_TASK  contains 
the  compiler  directive  to  give  a  task  object  of  this  task 
type  the  lowest  possible  priority.  This  allo%m  the  asynchro¬ 
nous  Imprecise  computation  mechanism,  operating  at  the 
highest  priority,  to  gain  control  of  the  processor.  Task 
type  TBST_TASK  also  contains  a  single  entry  call, 
STARTjCOMPUTATION.  The  procedure  START.COMPUTATION  is  needed 
to  rendezvous  with  the  computation  task  and  initialize  it. 

The  procedure  HANDLE  is  a  standalone  procedure  that  manipu¬ 
lates  the  final,  imprecise  result. 

Again,  once  the  asynchronous  computation  package 
specification  is  compiled  and  entered  into  the  user's 
library,  an  instantiation  of  the  generic  package 
ASYNCHRONOUS.IMPRECISB.COMPUTATION  can  be  made  using  the 
declarations  from  the  newly  constru«.  .ed  package  specifi- 
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cation.  This  Is  accoBq>lished  In  the  following  way: 


with  AS YMCHRONOUS.J ACOBI jCOMPUTATI ON ; 
use  AS YNCHROMOUS_JACOBI .COMPUTATION ; 
wi th  AS YNCHRONOUS.I MPRBCI SB.COMPUTATX  ON ; 
package  ASYNCHRONOUS.JACOBX.IMPRBCISB.COMPUTATION  is 
new  AS YNCHRONOUS.I MPRBCI SB.COMPUTATX  ON 
(COMPUTATION  »>  TBST.TASK, 

COMPUTATION.PTR  «>  TBST.PTR, 

RESULT.TYPB  ■>  RESULT.TYPB, 

BRROR.INDICATOR.TYPB  >>  BRROR.TYPE, 

INPUT.TYPB  »>  INPUT.TYPE, 

START.COMPUTATION  »>  START.COMPUTATION, 

HANDLE  ->  HANDLE); 


The  package  ASYNCHRONOUS.JACOBI.IMPRBCI SB.COMPUTATX ON  is 
created  fron  the  generic  tenplate,  substituting  the  new 
declarations  for  the  generic  parameters.  This  new  package 
contains  valid  IMPCALL  and  IMPRBTURN  procedures,  the  latter 
needed  by  the  computation  task  to  return  imprecise  results. 
At  this  point,  the  computation  package  body  containing  the 
procedure  bodies  and  task  type  body  is  constructed. 

The  package  body  of  ASYNCHRONOUS.JACOBI.COMPUTATION 
contains  the  following  procedure  bodies: 


procedure  START_COMPUTATION(THE_TASK  :  in  TEST.PTR; 

INPUT  :  in  INPUT.TYPB)  is 

begin 

THB.TASK . START.COMPUTATION ( INPUT ) ; 
end  START.COMPUTATION; 

procedure  HANDLE ( LAST.VALUE  :  in  out 

RESULT.TYPB; 

LAST.ERROR.INDICATOR  :  in  out 

ERROR.TYPB)  is 

begin 

put.line( "HANDLE  called  ..."); 
put ( "Computation  looped  "); 
put ( LAST.ERROR.INDICATOR ) ; 
put.llne("  times."); 
end  HANDLE; 
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The  procedure  STARTjCOMPUTATION  merely  calls  the  entry  point 
START_COHPUTATION  In  THBJTASK.  During  the  rendezvous, 
parameter  INPUT  Is  used  to  Initialize  the  computation  task. 
Procedure  HANDLE,  in  this  exaa^le,  merely  displays  the  number 
of  iterations  the  computation  completed.  Additional  state¬ 
ments  could  be  included  to  manipulate  the  imprecise  result 
based  on  this  number.  The  computation  package  body  also 
contains  the  body  of  task  type  TBSTJTASK: 


task  body  TBST.TASK  is 

. . .  local  variable  declarations  . . . 


begin 

accept  STARTJCOMPUTATION (INPUT: in  INPUT^TYPE)  do 
...  initialize  local  variables  with  input... 
end  STARTjCOMPUTATION; 
delay  duration'small; 

...  normalize  matrix  ... 
loop 

...  iterate  improvement  until  required 
accuracy  is  achieved  . . . 

...  compute  new  solution  vector 

using  method  in  [15,16]  ... 

...  find  absolute  difference 

between  old  and  new  elements . . 

. . .  let  present  estimate  be 
improved  estimate  ... 

...  set  finished  flag  if  within  accuracy  ... 
. . .  report  current  result 
with  IMPRBTURN  ... 
exit  when  FINISHED; 
end  loop; 


exception 


%ihen  NUMBRlCjERROR  «> 

put_.line(  "NUMERIC  ERROR...  "  & 

"Diverging  solution."); 


end  TESTjTASK; 


During  the  START_COMPUTATION  rendezvous,  local  variables  are 
assigned  the  values  of  INPUT  fields.  The  task  then  delays 
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the  snallest  possible  amount  o£  time.  This  delay  allows  task 
TIMER  to  determine  its  initial  delay  amount  and  then  delay 
itself.  After  the  coefficient  Mtrix  is  normalized,  the  task 
enters  a  loop.  This  loop  contains  the  Jacobi  algorithm  as 
specified  in  115,16).  If  the  required  accuracy  is  achieved, 
the  FINISHED  flag  will  be  set.  An  IMPRETURN  call  returns  the 
current  imprecise  result,  error  indicator,  and  state  of  the 
FINISHED  flag.  If  FINISHED  is  set,  the  loop  is  exited  and 
the  task  completes.  Appropriate  exception  handlers  are  set 
up  as  required  by  the  particular  computation.  With  the 
AS YNCHRONOUS_JACOBI .COMPUTATION  package  body  compiled  and  in 
the  user's  library,  the  following  VAX  Ada  procedure  can  use 
the  imprecise  Jacobi  computation  mechanism: 


wi t h  AS YNCHRONOUS.JACOBI.COMPUTATI ON ; 
use  ASYNCHRONOUS.JACOBI.COMPUTATION; 
wi t h  AS YNCHRONOUS.J ACOBI .1 MPREC I SE.COMPUTAT I ON ; 
use  ASYNCHRONOUS  JACOBI.IMPRBCISEjCOMPUTATION; 
with  CALENDAR;  ~  use  CALENDAR; 

With  TEXT.IO;  use  TBXT.IO; 

with  FLOAT.TEXT.IO;  use  FLOAT.TBXT.IO; 

with  INTEGER.TEXT.IO;  use  INTBCBR.TBXT.IO; 

procedure  ASYNCHRONOUS_JACOBI_TBST  is 

pragma  TIMB_SLICB(0.01); 


TBST.PTR  :«  new  TBSTJTASK; 

CALENDAR. TIME; 

RESULT.TYPB; 

FLOAT; 

INPUTJTYPB; 

begin 

for  INDEX  in  1  ..  N  loop 

put_line( "Enter  the  coefficients  and  "  A 

"right  hand  side  for  equation  "  & 
integer ' image( INDEX) ) ; 
for  NUM.COBFF  in  1  ..  N  loop 

get ( INPUT . COEFFICIENTS ( INDEX, NUMjCOEFF ) ) ; 


nX.TASR.fc’TK 

DEAD 

RESULT 

COMP.TIMB 

INPUT 
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end  loop; 

get ( 1 NPUT . R I OHT_HAND_S I DB ( I MDBX ) ) ; 
end  loop; 

for  INDEX  in  1  ..  N  loop 

I NPUT. XOLD( INDEX)  :«  0.0; 
end  loop; 

put ("Enter  tolerance  factor  «>  "); 
get(INPUT.TOL); 

put ("Enter  the  computation  duration ( secs )  •>  "); 
get(COMP_TIME); 

put_line( "Asynchronous  Jacobi  test  starting..."); 
DEAD  :»  CALENDAR. CLOCK  *  DURATION ( COMP _T I ME ) ; 
ASyNCHRONOUS_JACOBI _IMPRECI SE_COMPUTATrON . 

IMPCALL ( MY_TASK_PTR, 

DEAD, 

INPUT, 

RESULT); 

put_line( "Jacobi  TEST  ending...  "); 
for  INDEX  in  1  . .  N  loop 

put("X");  put (INDEX, WIDTH  «>  1);  put("  »>  "); 
put (RESULT (INDEX),  EXP  =>  0); 
new^line; 
end  loop; 

end  ASYNCHRONOUS  JACOBI.TEST; 


After  the  input  variables  are  given  their  appropriate  values, 
the  imprecise  computation  is  run  by  merely  calling  IMPCALL 
and  passing  it  the  necessary  parameters.  When  the  computa¬ 
tion  completes,  the  final  result  is  passed  back  in  the 
parameter  RESULT  and  IMPCALL  terminates.  A  complete  listing 
of  the  files  for  this  asynchronous  Jacobi  example  can  be 
found  in  i^pendix  F. 


4.3  Running  the  Examples 

All  of  the  preceding  examples  were  compiled  and  run  on  a 
VAX-11/780  at  the  83rd  Fighter  Weapons  Squadron's  Range 
Support  Facility  (RSF),  Tyndall  Air  Force  Base,  Florida.  The 
RSF  VAX  runs  the  VMS  operating  system  and  uses  the  DEC  Ada 
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compiler.  All  test  files  cosqpiled  and  linked  correctly.  The 
exan^le  tests  were  run  at  a  real-time  priority,  giving  them 
privilege  over  system  processes  such  as  the  swapper  and  all 
other  user  processes.  The  results  of  these  tests  are 
summarized  in  Tables  2  through  5.  Bach  table  contains  the 
duration  of  the  in^recise  computation  (TIME),  the  number  of 
iterations  completed  (ITERATIONS  COMPLETED),  and  the  amount 
of  time  the  computation  took  past  its  deadline  (PAST  DEAD¬ 
LINE)  . 

As  expected,  the  asynchronous  approach  proved  much 
faster,  almost  by  an  order  of  magnitude,  than  the  synchronous 
approach  in  the  circle  test.  This  algorithm  involves  a 
short,  simple  loop  that  must  be  repeated  10000  times  to 
produce  a  result  considered  precise.  In  this  example,  the 
synchronous  approach  yielded  more  consistent  and  lovet 
deadline  expiration  times.  This  is  expected  because  the 
synchronous  approach  maintains  total  control  over  the 
computation  loop.  In  the  Jacobi  test,  solving  a  linear 
system  of  three  equations  with  three  unknowns  required  only 
15  Iterations.  This  example  represents  the  other  side  of  the 
iteration  spectrum  as  compared  to  the  circle  test's  10000 
iterations.  In  addition  to  the  synchronous  approach  main¬ 
taining  its  lower  and  consistent  deadline  expiration  tiroes, 
it  also  produced  a  precise  result  ahead  of  the  asynchronous 
approach. 
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TIHB 


0.01 


1.00098B-02 


0.05 


1830 


1.00098B-02 


0.10 


4080 


1.00098B-02 


0.15 


5540 


O.OOOOOB^OO 


0.20 


8510 


O.OOOOOB-l-00 


0.25 


10000  (conplete) 


Table  2.  Asynchronous  Circle  Test  Results 


IIMB 


0.10 


O.OOOOOB-i-00 


0.25 


9.99500B>03 


0.50 


1510 


9.99500B-03 


1.00 


3040 


9.99500B-03 


2.00 


6300 


9.99500B-03 


2.50 


7470 


9.99500E-03 


3.00 


8880 


9.99500B-03 


3.50 


10000  (complete ) 


Table  3.  Synchronous  Circle  Test  Results 


time 


0.022 


7.9956B-03 


0.023 


7.0190B-03 


0.024 


5.9814E-03 


0.025 


15  (complete) 


Table  4.  Asynchronous  Jacobi  Test  Results 
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TIME 

0.0010 

0.0050 

0.0075 

0.0085 

0.0100 


ITfiRATIPHS  CQhPXigTBP,  PA3T  DBADLlMB(aac) 


1 

3 

4 
4 

15  (complete) 


8.97000E-03 

5.00000E-03 

2.50000E-03 

1.46000B-03 


Table  5.  Synchronous  Jacobi  Test  Results 


The  circle  and  Jacobi  imprecise  computation  exaiH>les  are 
indicative  o£  real-time  applications.  The  results  of  these 
exan^les  show  the  relative  merits  of  both  the  synchronous  and 
asynchronous  approaches . 
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5  Analysis  and  Conclusion 

5.1  Analysis  of  the  Test  Results 

In  analyzing  the  results  of  the  circle  and  Jacobi 
imprecise  computation  teats,  several  key  observations  can  be 
made.  First  and  foremost,  the  synchronous  and  asynchronous 
approaches  have  been  implemented  and  shown-  to  be  feasible. 
Both  approaches  have  demonstrated  their  consistent  behavior 
within  these  example  tests.  Second,  it  is  apparent  that  the 
approach  used  for  a  particular  application  should  depend  on 
the  nature  of  the  computation  involved.  The  asynchronous 
approach  demonstrated  its  capability  to  outdistance  the 
synchronous  approach  in  the  simple,  short,  highly  repetitive 
computation  loop  of  the  Monte  Carlo  circle  test.  On  the 
other  hand,  the  synchronous  approach  was  able  to  achieve  a 
precise  result  four  times  faster  than  the  asynchronous 
approach  in  the  computation- intensive  loop  of  the  Jacobi 
test.  Finally,  respectable  deadline  expiration  times  were 
turned  in  without  either  the  synchronous  or  asynchronous 
approaches  employing  any  deadline  checking  heuristic  algo¬ 
rithms.  For  example,  the  synchronous  mechanism  could 
maintain  a  running  average  of  the  execution  time  of  each 
iteration.  This  average  time  could  then  be  used  in  deciding 
whether  or  not  another  iteration  should  be  triggered. 

Another  possible  enhancement  is  changing  the  division  factor 
of  the  calculated  delay  time  in  the  asynchronous  approach. 
Altering  this  constant  can  help  compensate  for  a  lagging 


run-tine  system. 

The  results  turned  In  by  the  RSF  VAX  will  undoubtedly 
vary  betiireen  dissimilar  systems.  The  more  a  run-time  system 
is  geared  for  real-time  performance  the  better  the  results 
will  be.  Conversely,  the  less  a  run-time  system  is  geared 
for  real-time  performance  the  worse  the  results  will  be.  The 
same  circle  and  Jacobi  tests  run  on  a  VADS  machine  produced 
totally  unreliable  results.  It  was  not  uncommon  to  observe 
deadline  past  times  of  one  or  two  seconds  I  These  observa¬ 
tions  added  to  the  list  of  lessons  learned  in  this  project. 

5.2  Lessons  Learned 

Through  the  course  of  this  research  effort,  several 
problems  related  to  the  Ada  programming  language  and  its 
run-time  environment  were  identified.  First,  the  rendezvous 
is  too  costly  in  terms  of  execution  time.  The  rendezvous  has 
been  shown  to  require  fifty  tiroes  the  execution  tiroe  of  a 
procedure  call  {!].  This  is  the  one  major  drawback  to  the 
synchronous  approach  to  imprecise  computations.  The  asyn¬ 
chronous  approach  identified  more  severe  and  less  deter¬ 
ministic  problems. 

Although  the  Ada  tasking  model  is  priority  driven,  it  is 
not  preemptive.  For  this  reason,  priority  inversion  can 
occur  and  render  the  priority  system  useless.  In  the  context 
of  the  Monte  Carlo  circle  example,  when  the  higher  priority 
TIMER  task  becomes  ready  to  run  after  Its  prescribed  delay 
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anount,  it  should  not  have  to  wait  while  the  lower  priority 
compute  task  continues  to  execute.  In  this  environment, 
deadlines  can  be  missed  by  staggering  amounts  o£  time.  Time 
slices  can  be  used  to  compensate  for  this  problem. 

An  Ada  run-time  system  should  allow  the  user  to  specify 
the  time  slice,  or  the  amount  of  time  a  given  task  can  hold 
onto  the  processor.  VAX  Ada  provides  the  non-standard  pragma 
TIME_SLICE.  The  documentation  [8]  suggests  a  minimum  value 
of  0.01  seconds.  The  VADS  implementation  is  hard-wired  to  an 
unrealistic  one  second  124).  Running  the  asynchronous 
imprecise  computation  tests  on  both  systems  demonstrated  that 
a  VAX  Ada  implementation  can  achieve  consistent  deadline  past 
times  while  those  achieved  by  the  VAOS  implementation  were 
unruly  and  totally  unacceptable.  The  bottom  line  is  the 
lower  the  time  slice,  the  less  priority  inversion  effects  the 
computation. 

The  final  problem  area  is  the  sense  of  time  in  Ada.  The 
delay  statement  only  gives  a  minimum  delay.  When  this 
problem  is  coupled  with  large  time  slices  and  an  environment 
fostering  priority  Inversion,  delays  can  be  observed  orders 
of  magnitude  greater  than  the  requested  delay.  The  VAX  Ada 
asynchronous  imprecise  computation  results  show  acceptable, 
consistent  results.  With  the  time  slice  capability,  maximum 
delay  can  be  kept  in  check. 

These  problems  areas  do  not  spell  the  death  of  Ada,  nor 
the  death  of  any  project  implemented  in  Ada.  The  synchronous 
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and  asynchronous  approaches  to  inprecise  computation  have 
been  implemented  despite  these  drawbacks.  The  problems  are 
not  insurmountable.  Rather,  they  form  an  agenda  for  the 
evolution  of  the  Ada  programming  language. 

5.3  Conclusion 

The  goal  of  this  research  effort  was  to  investigate  all 
possible  approaches  to  implementing  imprecise  computations  in 
Ada.  Two  approaches  emerged  out  of  a  central  idea.  The 
synchronous  and  asynchronous  versions  of  the  atomic  computa¬ 
tion  loop  approach  were  distinguished  because  of  early  timing 
concerns  regarding  the  rendezvous.  Both  versions  were 
implemented  in  standard  Ada  code.  Each  version  was  demon¬ 
strated  using  the  Monte  Carlo  circle  example  and  the  Jacobi 
example.  Each  example  was  painstakingly  constructed  in  a 
straightforward  manner.  These  examples  illustrated  that  the 
synchronous  and  asynchronous  approaches  were  better  suited 
for  different  imprecise  computation  applications.  But  more 
importantly,  the  examples  showed  that  implementing  imprecise 
computations  in  Ada  is  entirely  possible. 
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Appendix  A 

SYMCHROHOUS  I MPRBCI SB  COMPUTATION 


with  CALENDAR; 
generic 

—  the  task  type  — 

type  COMPUTATION  is  United  private; 

—  the  pointer  type  to  the  task  type  — 
type  COMPUTATION.PTR  is  access  COMPUTATION; 

—  the  result  type  of  the  conputation  — 
type  RBSULT.TYPB  is  private; 

—  the  error  indicator  type  — 

type  BRROR.INDICATORJFYPB  is  private; 

—  the  input  argument  type  — 
type  INPUT_TYPB  is  private; 

—  procedure  to  initialize  the  compute  task  — 
with  procedure  INITIAL1ZB(THB_C0MPUTATI0N  :  in 

COMPUTATI ON_PTR ; 
INPUT  :  in 

INPUT_TYPB); 

—  procedure  to  call  a  rendezvous  with  compute  loop  -- 

with  procedure  COMPUTB(THB  COMPUTATION  :  in 

COMPUTATION_PTR; 
COMPUTATION^COMPLETB  :  out 

boolean); 

--  procedure  to  call  a  rendezvous  with  a  handler  — 
with  procedure  HANDLE(THB_COMPUTATION  :  in 

COMPUTATION_PTR; 
HANDLER_NUMBBR  :  in 

integer; 

LAST.VALUB  :  in 

RESULT_TYPE; 

LAST  ERROR_INDICATOR  :  in 

BRROR_INDICATOR_TYPE) ; 

—  procedure  to  stop  the  compute  task  — 
with  procedure  STOP(THE_COMPUTATION  :  in 

COMPUTATION_PTR) ; 


package  SYNCHRONOUS_IMPRECISE_COMPUTATION  is 

procedure  IMPCALL(THE_CONPUTATION  :  in  out 

COMPUTATI ON_PTR; 
THE.HANDLER  :  in  integer; 

DEADLINE  :  In  CALENDAR .TIME; 

INPUT  :  in  INPUT_TYPE; 

PINAL_RESULT  :  out  RESULT_TYPE ) ; 
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procedure  IHPRBTURN( INTBRMBOIATB.RBSULT  :  in 

RBSULT^TYPB; 

BRROR.IHDICATOR  :  in 

BRROR.I  NDI CATOR_TYPB ) ; 

end  SYNCHRONOUS_IMPRBCISB_COMPUTATIOM; 
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with  TEXT_IO;  uae  TEXT_IO; 

with  PLOAT_TEXT_IO;  use  FLOAT_TEXT_IO; 

package  body  SYNCHROMOUS_IHPRECISE_COMPUTATION  is 

CURREHT_yALUE  :  RESULT_TYPE; 

CURRENT_ERR0R_INDICAT0R  :  ERROR, INDICATOR_TYPE; 


pr  oced  ur e  I HPCALL ( THE.COMPUTATl ON 

THE  HANDLER 

DEADLINE 

INPUT 

PINAL  RESULT 


in  out 

COMPUTATI ON_PTR ; 
in  integer; 
in  CALENDAR. TIME; 
in  INPUT_TYPE; 
out  RESULT_TYPE)  is 


COMPUTATI ON.COHPLETED  :  boolean; 

TIME_HACK  :  CALENDAR. TIME; 

begin 

INITIALIZE (THE.COMPUTATION,  INPUT) ; 
loop 

COMPUTE ( THE.COMPUTATI ON , 

COMPUTATIONjCOMPLETED ) ; 
exit  when  COMPUTATIONJCOMPLETED; 

TIMEjHACK  :»  CALENDAR .CLOCK; 

if  CALENDAR. ''>"(TIMB_HACK,  DEADLINE)  then 
put ( "deadline  expired  by  "); 
put  (£  loat  ( ca  lender  TI  MBjHACK , 

deadline))^  exps>0); 
put_llne( "secs .  Calling  handler..."); 

HANDLE ( THEjCOMPUTATI ON , 

THBjHANDLER, 

CURRENTjVALUE, 

CURRENTjERROR  INDICATOR ) ; 

exit; 
end  if; 
end  loop; 

STOP ( THEjCOMPUTATI ON ) ; 

PINALjRBSULT  :»  CURRENT jVALUE; 
end  IMPCALL; 


procedure  IMPRBTURN( INTERMBDIATBjRESULT  :  in 

RESULTjTYPE; 

BRRORjINDICATOR  :  in 

ERROR  INDICATORjTYPE)  is 


begin 

CURRENTjVALUE  :*  INTERMBDI ATE_RESULT; 

CURRBNTjERRORjINDICATOR  ;»  ERROR_INDICATOR; 
end  IMPRETURN; 

end  SYNCHRONOUS _I MPRBCI SB jCOMPUTATI ON; 
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Appendix  B 

ASYNCHRONOUS  IMPRECISE  COMPUTATION 
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with  CALENDAR; 
generic 

—  the  task  type  -- 

type  COMPUTATION  la  limited  private; 

—  the  pointer  type  to  the  task  type  — 
type  COMPUTATION_PTR  la  access  COMPUTATION; 

—  the  result  type  of  the  computation  — 
type  RBSULT.TYPE  is  private; 

—  the  error  indicator  type  — 

type  BRROR_INDICATOR_TYPE  Is  private; 

—  the  Input  argument  type  — 
type  INPUT_TYPE  Is  private; 

—  procedure  to  start  compute  loop  — 

with  procedure  START_COMPUTATION(THE_COMPUTATION  :  In 

COMPUTATI ON_PTR ; 
INPUT  :  In 

INPUT_TYPB) ; 

—  procedure  to  call  a  handler  — 

with  procedure  HANDLE ( LAST_VALUB  :  In  out 

RESULT_TYPB; 

LASTJBRROR_INDICATOR  :  In  out 

BRROR_INDICATOR_TYPB) ; 


package  ASYNCHRONOUS.IMPRBCISBjCOMPUTATION  Is 

procedure  IMPCALL(THE_COMPUTATION  :  in  out 

COMPUTATI ON_PTR ; 

DEADLINE  :  In  CALENDAR. TIMB; 

INPUT  :  in  INPUT_TYPE; 

FINAL_RESULT  :  out  RESULT_TYPE) ; 

procedure  IMPRETURN( INTERMEDIATE_RESULT  :  In 

RESULT_TYPE; 

ERROR_IND1CATOk  :  In 

ERROR_I NDI CATOR_TYPE  ; 
STOP_PLAG  ;  in  out 

boolean) ; 

end  AS YNCHRONOUS_I MPREC I SB.COMPUT AT I ON ; 
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with  TEXT.IO;  use  TEXT  10; 

with  PLOAT_TEXT_IO;  use  PLOAT_TEXT_IO; 

package  body  ASYNCHRONOUS_IMPRECISE_COMPUTATION  is 

CURREHT_VALUE  :  RESULT_TYPE; 

CURRENT_ERROR_IMDICATOR  :  ERROR_INDICATOR_TYPE; 
STOP_COMPUTATION_PLAG  :  boolean  PALSE; 

task  TIMER  is 

pragma  PRI0RITY(7); 

entry  RUN_JOB ( THE_JOB  :  in  out  COMPUTATION_PTR; 

INPUT  :  in  INPUT_TYPE; 

DEADLINE  :  in  CALENDAR. TI ME ) ; 

end  TIMER; 

task  body  TIMER  is 

COMPUTATIONjCOMPLETED 
TIME.HACK 
TIME_LEPT 
DELAY^TIME 

HACK17  hack 2 

begin 

accept  RUN_JOB(THB_jJOB  :  in  out  COMPUTATION_PTR; 

INPUT  :  in  INPUT_TYPE; 

DEADLINE  :  in  CALENDAR. TIME)  do 

START_COMPUTATION(THE_JOB,  INPUT) ; 
loop 

TIME.HACK  CALENDAR. CLOCK; 

TIME_LEPT  :>  float (CALENDAR DEADLINE, 

TIMB_HACK ) ) ; 

DELAY.TIME  ;=  DURATION (TIME_LEPT  /  2.0); 
if  DELAY_TIME  <  DURATION  *  SMALL  and  then 
DELAY.TIMB  >  0.0  then 
DELAY_TIME  :=  0.0; 
end  if; 

if  OELAY_TIME  >  0.0  then 
put ( "delaying  "); 
put ( float (OELAY_TIMB) ); 
put_line("  secs."); 

HACKl  :>  CALENDAR. CLOCK; 
delay  DELAY.TIME; 

HACK 2  CALENDAR . CLOCK ; 

put ("Actual  delay  was  "); 

put (float (CALENDAR. "-"(HACK2, HACKl) ) ); 

put_line("  secs."); 

else 

put ( "DEADLINE  expired  by  " ) ; 
pu  t ( f 1 oa  t ( CALENDAR . " - " ( T I ME_H ACK , 

DEADLINE) ) ); 


:  boolean; 

:  CALENDAR. TIME; 
:  float; 

:  DURATION; 

:  CALENDAR. TIME; 


put_line("  secs."); 
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♦  r 


STOP_COMPUTATION_PLAG  :»  TRUE; 
HANDLE ( CURRBMT.VALUB, 

CURRBNT_BRROR_INDICATOR ) ; 

and  if; 

exit  when  STOP.COMPUTATION^PLAG; 
end  loop; 
end  RUN_JOB; 
end  TIMER; 


prgg^ure  IMPCALL(THB_COMPUTATION 

DEADLINE 

INPUT 

FINAL  RESULT 


in  out 

COMPUTATI ON_PTR ; 
in  CALENDAR. TIME; 
in  INPUT_TYPE; 
out  RESULT_TYPE)  is 


begin 

TI HER . RUN_JOB ( THE_COMPUTATI ON , 
INPUT, 

DEADLINE); 

FINAL_RESULT  :«  CURRENT.VALUB; 
end  IMPCALL; 


procedure  IMPRETURN( INTERMEDIATB.RESULT  :  in 

RESULT.TYPE; 

ERROR_INDICATOR  :  in 

BRROR_INDICATOR_TYPE; 
STOP_FLAG  :  in  out 

boolean)  is 

begin 

if  not  STOP_COMPUTATION_PLAG  then 

CURREMT_VALUB  :«  INTBRMBDIATB_RESULT; 

CURRENT_BRROR_INDICATOR  ;»  ERROR_INDICATOR; 
end  if; 

—  If  incoming  stop  flag  is  FALSE,  then  this  is 

—  merely  a  classic  IMPRBTURN  call.  If  TRUE,  then 

—  this  is  a  signal  that  the  computation  has 

—  completed. 

if  not  STOP_FLAG  then 

STOP_FLAG  ;■  STOP_COMPUTATION_PLAG; 

else 

STOP_COMPUTATION_PLAG  ;»  STOP_FLAG; 
end  if; 

end  IMPRBTURN; 


end  ASYNCHRONOUS_IMPRECISE_COMPUTATION; 
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Appendix  C 

Synchronous  Circle  Test  Files 


with  CALENDAR;  use  CALENDAR; 

package  SYNCHRONOUSjCIRCLBjCOMPUTATION  is 

subtype  RESULT.TYPE  is  float; 

subtype  ERROR_TYPE  is  integer; 

type  INPUT.TYPE  is  record 

LOOPSJTOjCOMPLETE  :  integer; 

RADIUS  :  float; 

end  record; 

task  type  TEST_TASK  is 

entry  INITIALIZB( INPUT  :  in  INPUT_TYPB); 

entry  COMPUTE (COMPUTATION_COMPLBTB  :  out  boolean); 

entry  HANDLER (1  ..  2 ) ( LAST_RESULT  :  in  RESULT_TYPE 

LAST.BRROR  :  in  ERROR.TYPB) 

entry  STOP; 
end  TBSTJPASK; 

type  TEST_PTR  is  access  TEST_TASK; 

procedure  INITIALIZB(THE_TASK  :  in  TBST_PTR; 

INPUT  :  in  INPUT^TYPB); 

procedure  COMPUTE ( THE_TASK  :  in  TEST_PTR 

COMPUTATION_COMPLETE  ;  out  boolean) 

procedure  HANDLE ( THE.T ASK  :  in  TBST.PTR; 

HANDLER_NUMBBR  :  in  integer; 

LAST_VALUE  ;  in  RESULT_TYPE 

LAST_ERROR_IMDICATOR  :  in  ERROR_TYPE) 

procedure  STOP ( THE_TASK  ;  in  TEST_PTR); 


end  SYNCHRONOUS_CIRCLE_COMPUTATIOM; 
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with  TEXT  10;  use  TEXT  10; 

with  PL0AT_TEXT_I0;  use  PL0AT_TEXT_I0; 

with  INTEGER_TEXT_I0;  use  INTEGER_TEXT_IO; 

with  SyNCHR0N0US_CIRCLE_IMPRBCISE_C0HPUTATI0N; 

use  S  YNCHR0N0US_CI RCLE.I HPRECI SE.COMPUTAT I ON ; 

with  RANDOM_MUMBER_GENERATOR; 

use  RANDOH_NUMBER_GENERATOR; 

package  body  SYNCHRONOUS.CIRCLE.COMPUTATION  is 

procedure  INITIAL1ZE(THE_TASK  :  in  TEST.PTR; 

INPUT  :  in  INPUT_TYPB)  is 

begin 

THE_TASK . I N I TI AL I ZE ( I NPUT ) ; 
end  INITIALIZE; 

procedure  COMPUTE ( THB_TASK  :  in  TBST_PTR; 

COMPUTATION_COMPLETB  :  out  boolean)  is 

begin 

THE_TASK . COMPUTE ( COMPUTATION_COMPLETE ) ; 
end  COMPUTE; 

procedure  HANDLE ( THB_T ASK  :  in  TBST_PTR; 

HANDLER.NUMBBR  :  in  integer; 

LAST_VALUE  ;  in  RESULT_TYPE; 

LAST_ERROR_INDICATOR  :  in  ERROR_TYPE)  is 

begin 

THE_TASK . HANDLER ( HANDLBR.NUMBBR ) 

(LAST_VALUE, 

LAST_ERROR_INDICATOR ) ; 

end  HANDLE; 

procedure  STOP ( THE_T ASK  :  in  TEST_PTR)  is 
begin 

THE_TASK.STOP; 
end  STOP; 


task  body  TEST_TASK 

PINISHED 

ERROR 

M 

N 

RADIUS 

RADIUS.SQUARBD 

DIAMETER 

SQUARE.AREA 

X,  Y 

AREA 

LOOP_NUM 

SEED 


is 

boolean  false; 

ERROR_TYPE  :=  0; 

integer  :«  0; 

integer  0; 

float; 

float; 

float; 

float; 

float; 

RESULT_TYPE; 
integer ; 
integer; 
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begin 

accept  INITIALIZE (INPUT 


RADIUS 

RADIUS.SQUARBD 
DIAMETER 
SQUARE.ARBA 
LOOP  NUM 

seed” 

end  INITIALIZE; 
loop 

select 


In  INPUT_TYPE)  do 


INPUT. RADIUS; 

RADIUS  **  2; 

2.0  *  RADIUS; 

DIAMETER  **  2; 

INPUT . LOOPS_TO_COMPLETE; 
1; 


accept  COMPUTE (COMPUTATION_COMPLETE  :  out 

boolean)  do 

RANDOM(X,SBED); 

RANDOM (Y, SEED) ; 

X  X  *  DIAMETER  -  RADIUS; 

Y  :«  Y  *  DIAMETER  -  RADIUS; 

N  N  +  1; 

if  (X**2  +  Y**2)  <=  RADIUS_SQUARED  then 

M  :=  M  +  1; 

end  if; 

ERROR  :=  ERROR  *  1; 
if  ERROR  >  LOOP_NUM  then 

COMPUTATION_COMPLETE  :=  TRUE; 

else 

COMPUTATION^COMPLETE  :=  FALSE; 
end  if; 

if  ERROR  rem  10  »  0  or 
ERROR  >  LOOP.NUM  then 
AREA  :=  SQUARB.AREA  * 

float(M)  /  float(N); 
IMPRETURN(AREA,  ERROR); 
end  if; 
end  COMPUTE; 


or 


accept  HANDLER(l) 

(LASTJRESULT  ;  in  RESULT_TYPB; 

LAST.ERROR  ;  in  ERROR_TYPE)  do 
—  output  number  of  iterations  — 
put ("Computation  looped  "); 
put ( LAST_ERROR ) ; 
put_llne("  times."); 

—  IMPRETURN  if  modification  made  — 
end  HANDLER; 


accept  HANDLER(2) 

(LAST_RESULT  :  in  RESULT_TYPE; 
LAST_ERROR  :  in  ERROR_TYPE)  do 
null;  —  this  handler  does  nothing  -- 
—  IMPRETURN  if  modification  made  — 
end  HANDLER; 
or 


accept  STOP  do 

FINISHED  :»  true 
end  STOP; 
end  select; 
exit  when  FINISHED; 
end  loop; 
end  TEST_TASK; 

end  S  YNCHRONOUS_CI RCLE_COMPUTATI ON ; 


with  SYHCHRONOUS_CIRCLE_COMPUTATIOM; 
use  SYMCHRONOUS.CIRCLBjCOMPUTATION ; 

With  S YMCHROMOUS_I MPRECl SB.COMPUTAT 1 ON ; 
package  SYNCHR0N0US_CIRCLE_IMPRBCISB_C0HPUTAT10M  i 
new  S YNCHROMOUS.I MPRBCI SE.COMPUTATI ON 

(COMPUTATION  »>  TEST_TASK, 

COMPUTATION_PTR  »>  TEST_PTR, 

RESULT_TYPE  =>  RBSULT_TYPE, 

ERROR_INDICATOR_TYPE  =>  ERROR_TYPE, 

INPUT_TYPE  =>  INPUT_TYPE, 

INITIALIZE  =>  INITIALIZE, 

COMPUTE  =>  COMPUTE, 

HANDLE  =>  HANDLE, 

STOP  =>  STOP ) ; 


with  SYMCHRONOUS.CIRCLEjCOMPUTATION; 

use  SYNCHROHOUSjCI RCLBjCOMPUTATI ON ; 

with  S YNCHROMOUS _C I RCLB_I MPRBC I SB.COHPUTAT I ON ; 

use  SYNCHRONOUS_CIRCLB_IMPRBCISB_COMPUTATION; 


with  CALENDAR; 

with  TBXT_IO; 

with  PLOAT_TEXT  10; 

with  INTEGER_TEXT_IO; 

procedure  SYNCHRONOUSjCIRCLBJTBST  is 

pragma  TIME_SLICE( 0 . 01 ) ; 


use  CALENDAR; 
use  TEXT_IO; 
use  FLOAT_TEXT_IO; 
use  INTEGER_TEXT_IO; 


MY_TASK_PTR 
DEAD 
RESULT 
COMP_TIMB 
MY  INPUT 


TEST_PTR 
CALENDAR. TIME; 
RESULT_TYPE; 
float; 
INPUT_TYPE; 


=  new  TEST_TASK; 


begin 

put ("Enter  the  circle  radius  »>  "); 
get ( MY_I NPUT . RADIUS ) ; 

put ("Enter  the  number  of  iterations  to  complete  =>  ") 
get ( MY_INPUT . L00PS_T0_C0MPLETE ) ; 

put ("Enter  the  computation  duration  in  seconds  =>  "); 
get(COMP_TIME); 

put_line( "Synchronous  CIRCLE  TEST  starting..."); 

DEAD  :=  CALENDAR. CLOCK  *  DURATIOM(COMP_TIME) ; 

I MPCALL ( M Y_TASK_PTR , 

1, 

DEAD, 

MY_INPUT, 

RESULT ) ; 

put ("TEST  ending...  RESULT  »>  "); 
put (RESULT,  EXP  =>  0,  APT  »>  2); 


put (RESULT,  EXP  =>  0,  AF 
new_line; 

end  SYNCHRONOUS_CIRCLE_TBST; 
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with  CALENDAR;  use  CALENDAR; 

with  SYSTEM;  use  SYSTEM; 

package  ASYNCHRONOUS_CIRCLB_COMPUTATION  Is 

subtype  RBSULT_TYPE  Is  float; 

subtype  BRROR_TYPE  Is  Integer; 

type  INPUT_TYPE  is  record 

LOOPS_TO_COMPLETE  :  integer; 

RADIUS  :  float; 

end  record; 

task  type  TBST_TASK  is 
pragina  PRIORITY(O); 
entry  START_COMPUTATION( INPUT  :  in 
end  TEST_TASK; 

type  TESTJPTR  is  access  TESTJTASK; 

procedure  START_COMPUTATION(THB_TASK  : 

INPUT  : 


procedure  HANDLE (L AS T.VALUB 

LAST.ERROR  INDICATOR 


INPUT_TYPB); 


in  TEST  PTR; 
in  INPUT_TYPE); 

in  out 

RESULT_TYPE; 
in  out 

ERROR_TYPE); 


end  AS  YNCHRONOUS  _C I RCLE.COMPUTAT I ON ; 
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with  TEXT_IO;  use  TEXT_IO; 

with  FLOAT_TEXT_IO;  use  FLOAT_TEXT_I 0 ; 

with  INTEGER_TEXT_IO  use  INTEGER_TEXT_IO; 

with  ASyNCHRONOUS_ClRCLE_IMPRECISE_COMPUTATION; 

us  e  AS  YNCHROHOUS  _C I RCLE_I MPRBCI SE.COMPUT AT ION; 

with  RANDOM_MUHBER_GEMERATOR; 

use  RAMDOH_NUMBER_GBNERATOR; 

package  body  ASYNCHRONOUS.CIRCLE.COHPUTATION  is 

procedure  START_COMPUTATION(THE_TASK  ;  in  TEST_PTR; 

INPUT  ;  in  INPUT_TYPE) 

is 

begin 

THE_TASK . START_COMPUTATION ( INPUT ) ; 
end  START_COMPUTATION; 

procedure  HANDLE (LAST_VALUB  :  in  out 

RESULT_TYPE; 

LAST_ERROR_INDICATOR  :  in  out 

ERROR_TYPK)  is 

begin 

put  (  "Coraputatlon  looped  **); 
put ( LAST_ERROR_INDICATOR ) ; 
put  llneC  tiroes.*'); 
end  HANDLE; 


task  body  TEST.TASK  is 


FINISHED 

boolean 

ERROR 

ERROR_TYPB 

M 

integer 

N 

Integer 

RADIUS 

float; 

RADIUS_SQUARED 

float; 

DIAMETER 

float; 

SQUARE  AREA 

float; 

X,  Y 

float; 

AREA 

float; 

LOOP  NUM 

Integer; 

SEED 

integer; 

false; 

0; 

0; 

0; 


begin 

accept  START_COMPUTATI ON (INPUT  ;  in  INPUT_TYPE)  do 
RADIUS  :»  INPUT. RADIUS; 

LOOP_NUM  :<=  INPUT.LOOPS_TO_COMPLETE; 

RADIUS.SQUARED  RADIUS  **  2; 

DIAMETER  :=  2.0  *  RADIUS; 

SQUARE.AREA  DIAMETER  **  2; 

SEED  :  3!  1 ; 

end  START_COMPUTATION; 
delay  DURATION 'SMALL; 


loop 

RANDOM (X, SEED); 

RANDOM (Y, SEED); 

X  :«  X  *  DIAMETER  -  RADIUS; 

Y  Y  *  DIAMETER  -  RADIUS; 

N  :«  N  +  1; 

if  (X**2  +  Y**2)  <=  RADIUS_SQUARED  then 
M  ;=  M  +  1; 
end  if; 

ERROR  :=  ERROR  ^1; 
if  ERROR  >  LOOP_NUM  then 
FINISHED  TRUE; 
end  if; 

if  (ERROR  rem  10  =  0)  or  FINISHED  then 

AREA  SQUARE.AREA  *  float(M)  /  float (N) 
IMPRETURN(AREA,  ERROR,  FINISHED); 
end  If; 

exit  when  FINISHED; 
end  loop; 
end  TEST_TASK; 

end  ASYNCHRONOUSjCIRCLB.COMPUTATIOM; 


with  ASYNCHRONOUS_CIRCLE_COMPUTATION; 
use  ASYNCHRONOUS_CIRCLB_COMPUTATION ; 

with  asymchronous_imprecFsb_computation; 

package  ASYNCHRONOUS_CIRCLE_IMPRBCISB_COHPUTATION  i 
new  AS YNCHRONOUS_I  HPRECI SBjCOHPUTATI ON 
(COMPUTATION  »>  TEST_TASK, 

COMPUTATION_PTR  »>  TEST_PTR, 

RESULT_TYPE  =>  RESULT_TYPE, 

ERROR_INDICATOR_TYPE  =>  ERROR.TYPB, 

INPUT_TYPE  =>  INPUT_TYPE, 

START_COMPUTATION  =>  START_COMPUTATION, 

HANDLE  =>  HANDLE); 
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with  ASYNCHROMOUS_CIRCLE  COMPUTATION; 
use  AS YNCHROHOUS.CI RCLeIcOMPUTATI ON ; 

With  ASYNCHRONOUS.CIRCLE  IHPRECISE_COMPUTATION; 

use  ASYNCHRONOUS_CIRCLE_IMPRECI SE.COMPUTATION; 

with  CALENDAR;  use  CALENDAR; 

with  TBXT_IO;  use  TEXT_IO; 

with  FLOAT_TEXT_IO;  use  FLOAT_TEXT_IO; 

with  INTEGER_TEXT_IO;  use  I NTEGBR_TEXT_I O 

procedure  ASYNCHRONOUS_CIRCLB_TEST  is 

pragma  TIME_SLICE( 0. 01 ) ; 


MY_TASK_PTR 
DEAD 
RESULT 
COMPJTIME 
MY  INPUT 


TEST_PTR  :=  new  TEST_TASK; 

CALENDAR. TIME; 

RESULT_TYPE; 

float; 

INPUT_TYPE; 


begin 

put ("Enter  the  circle  radius  »>  "); 
get ( MY_INPUT . RADIUS ) ; 

put ("Enter  the  number  of  iterations  to  complete  =>  ") 
get ( MY_I NPUT . LOOPS_TO_COMPLETE ) ; 

put ("Enter  the  computation  duration  in  seconds  =>  "); 
get ( COMP  JPIME); 

put_line( "Asynchronous  CIRCLE  TEST  starting..."); 

DEAD  CALENDAR. CLOCK  +  DURATION(COMP_TIME) ; 

I MPCALL ( M Y_TASK_PTR , 

DEAD, 

MY_INPUT, 

RESULT); 

put ("CIRCLE  TEST  ending...  CIRCLE  AREA  RESULT  =>  "); 
put (RESULT,  EXP  =>  0,  AFT  «>  2); 


new_line; 

end  ASYNCHRONOUS_CIRCLE_TEST; 
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vith  CALENDAR;  use  CALENDAR; 

package  SYNCHRONOUS.JACOBI .COMPUTATION  is 

N  :  constant  integer  3; 

type  RESULT.TYPE  is  azrayd  ..  N)  of  float; 

subtype  ERRORJTYPB  is  integer; 

type  COEPPICIENT.TYPE  is  arrayd  ..  N,  1  ..  N) 
of  float; 

type  INPUT.TYPE  is  record 

COEPPICIENTS  :  COEPPICIENT.TYPE; 

RIGHT.HAND.SIDE  :  RESULT.TYPE; 

XOLD  :  RESULT.TYPE; 

TOL  :  float; 

end  record; 

task  type  TEST.TASK  is 

entry  INITIALIZE( INPUT  :  in  INPUT.TYPE); 

entry  COMPUTE (COMPUTATION.COMPLETE  :  out  boolean); 

entry  HANDLER (1  ..  2) 

(LAST.RESULT  :  in  RESULT.TYPE; 

LAST.BRROR  :  in  ERROR JPYPE); 
entry  STOP; 
end  TEST.TASK; 

type  TEST.PTR  is  access  TEST.TASK; 

procedure  INITIALIZE(THEjrASK  :  in  TEST.PTR; 

INPUT  ;  in  INPUT.TYPE); 

procedure  COMPUTE ( THEJT ASK  :  in  TEST.PTR; 

COMPUTATlONjCOMPLETE  :  out  boolean); 

procedure  HANDLE (THE_T ASK  :  in  TEST.PTR; 

HANDLER.NUMBER  :  in  integer; 

LAST.VALUB  :  in  RESULT.TYPE 

LAST_ERROR_INDICATOR  :  in  ERROR.TYPE) 

procedure  STOP(THE.TASK  :  in  TEST.PTR); 

end  S  YNCHRONOUS.J ACOB I .COMPUTATI ON ; 
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with  TEXT_IO;  use  TEXT_IO; 

with  FLOAT_TEXT_IO;  use  FLOAT_TEXT_I 0 ; 

With  INTEGER_TEXT_IO;  use  INTEGER_TEXT_IO; 

with  SYNCHRONOUS_JACOBI_IMPRECISE_COMPUTATION; 

use  SyNCHRONOUS_JACOBI_IHPRECISE_COMPUTATION; 

package  body  SYNCHRONOUS.JACOBI^COMPUTATION  is 

procedure  INITIALIZE(THE_TASK  :  in  TEST.PTR; 

INPUT  :  in  INPUT_TYPE)  is 


begin 

THE.TASK  .INITIALIZEd MPUT )  ; 
end  INITIALIZE; 

procedure  COMPUTE ( THB_T ASK  :  in  TEST_PTR; 

COMPUTATION  COMPLETE  :  out  boolean)  is 


begin 

THB_TASK . COMPUTE ( COMPUTATION_COMPLETE ) ; 
end  COMPUTE; 


procedure  HANDLE ( THE_TASK 

HANDLER.NUMBER 

LAST_VALUE 

LAST_ERROR_INDICATOR 


in  TEST__PTR; 
in  integer; 
in  RESULT_TYPB; 
in  ERROR  TYPE)  is 


begin 

THB.TASK . HANDLER ( HANDLER.NUMBER ) 

(LAST  VALUE,  LAST_BRROR_INDICATOR ) ; 
end  HANDLE; 


procedure  STOP ( THE_TASK  :  in  TEST_PTR)  is 
begin 

THB_T ASK. STOP; 
end  STOP; 

task  body  TBST.TASK  is 


FINISHED 

ERROR 

COBFF 

R_H_S 

XOLD 

TOL 

XNEV 

C 

0 

MAXNBW, 

KNEW, 

MAXDIF, 

DIFF 


:  boolean  false; 

:  ERROR_TYPB  :=  0; 

:  COEFFICIENT_TYPB; 

:  RESULT_TYPB;  —  right-hand-side  -- 

:  RESULT_TYPE;  --  solution  guess  — 

:  float;  —  tolerance  — 

;  RESULTJTYPE;  —  new  solution  -- 

;  COEFFICIENT_TYPE;  —  norm  coeff 
:  RESULT_TYPB;  --  normalized  r-h-s 

— "NEV**  in  text  but  an  Ada  reserved  word. 

:  float; 
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begin 

accept  INITIALIZE (INPUT  :  in  INPUT.TYPB)  do 
COEPF  INPUT. COEFFICIENTS; 

R_H_S  :«  INPUT.RIGHT_HAND_SIDE; 

XOLD  :«  INPUT. XOLO; 

TOL  :=  INPUT. TOL; 

—  Noraalize  matrix  — 
for  J  in  1  . .  N  loop 

for  K  in  1  . .  J  -  1  loop 

C(J,K)  :=  COEFP(J,K)  /  COEFF(J,J); 
end  loop; 

for  K  in  J  1  . .  N  loop 

C(J,K)  :=  COEFF(J,K)  /  COEFF(J,J); 
end  loop; 

D(J)  ;»  R_H_S(J)  /  COBFF(J,J); 
end  loop; 
end  INITIALIZE; 

loop 

select 

accept  COMPUTE ( COMPUT AT I ON_COMPLBTE  :  out 

boolean)  do 

MAXNEW  :=>  0.0; 

HAXDIF  :=  0.0; 
for  J  in  1  . .  N  loop 
XNBV(J)  :=  D(J); 
for  K  in  1  . .  J  -  1  loop 

XNBV(J)  :«  XNEW(J)  -  C(J,K) 

*  XOLD(K); 

end  loop; 

for  K  in  J  -t-  1  .  .  N  loop 

XNEV(J)  XNBW(J)  -  C(J,K) 

*  XOLD(K); 

end  loop; 

—  Find  max  absolute  difference 
—  between  old  and  new  elements . 
DIFF  :>  ABS(XNBW(J)  -  XOLD(J)); 
if  DIFF  >  HAXDIF  then 
MAXDIF  DIFF; 
end  if; 

NNBW  :«  ABS(XNBW( J) ); 
if  NNBV  >  MAXNEW  then 
MAXNEW  NNEW; 
end  if; 
end  loop; 

ERROR  :«  ERROR  *  1; 

—  Let  present  estimate  be  improved 
—  estimate 

XOLDd  ..  N)  XNEWd  ..  N); 
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if  MAXMBV  /«  0.0  and  then 

(MAXDIP  /  MAXMBV)  <»  TOL  then 
COMPUTATION_COMPLBTB  ;=  TRUE; 

else 

COMPUTATIOM.COMPLBTB  :*  FALSB; 
end  If; 

—  Report  current  result  — 

I MPRBTURN ( XMBV,  ERROR ) ; 

end  COMPUTE; 
or 

accept  HANDLERd) 

(LAST_RESULT  :  in  RESULT_TYPE; 
LAST_ERROR  :  in  BRROR_TYPE)  do 
put ( "Computation  looped  "); 
put(LAST_ERROR); 
put_line("  times."); 

—  IMPRETURM  if  modification  made  — 
end  HANDLER; 
or 

accept  HANDLBR(2) 

(LAST_RESULT  :  in  RESULT_TYPB; 
LAST_ERROR  ;  in  BRROR.TYPB)  do 
null;  —  this  handler  does  nothing  — 
—  IMPRETURM  if  modification  made  — 
end  HANDLER; 
or 

accept  STOP  do 

FINISHED  :«  true; 
end  STOP; 
end  select; 
exit  when  FINISHED; 
end  loop; 
end  TEST_TASK; 

end  SYMCHRONOUS_JACOBI_COMPUTATION; 
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with  SyNCHRONOUS_JACOBI .COMPUTATION; 
use  S  YNCHRONOUS  _J ACOB I _COMP UTAT I ON ; 
with  SYNCHRONOUS_IMPRECISE_COMPUTATION; 
package  SYNCHRONOUS_JACOBI_IMPREClSE_COMPUTATION  is 
new  S YNCHRONOUS.I MPRECI SE.COHPUTATI ON 
(COMPUTATION  »>  TEST.TASK, 

COMPUTATION.PTR  *>  TEST.PTR, 

RESULTJTYPE  »>  RESULT.TYPE, 

ERROR_INDICATOR_TYPE  =>  ERROR.TYPE, 

INPUT.TYPE  =>  INPUT.TYPE, 

INITIALIZE  »>  INITIALIZE, 

COMPUTE  =>  COMPUTE, 

HANDLE  ->  HANDLE, 

STOP  =>  STOP); 
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with  S YHCHRONOUS_J ACOBI _COMPUTATION ; 

use  SYNCHRONOUS_JACOBI_COMPUTATION ; 

with  SYNCHRONOUS_JACOBI_IMPRECISE_COMPUTATION; 

use  SYNCHRONOUS_JACOBI_IMPRECISB_COMPUTATION; 

with  CALENDAR;  use  CALENDAR; 

with  TEXT_lO;  use  TSXT_IG; 

with  FLOAT_TEXT_IO;  use  PLOAT_TEXT_I 0 ; 

with  INTEGER_TEXT_IO;  use  INTEGER_TEXT_IO; 

procedure  SYNCHRONOUS_JACOBI_TEST  is 


MY_TASK_PTR 

DEAD 

RESULT 

COMP_TIME 

INPUT 


TEST_PTR  :=  new  TEST_TASK; 

CALENDAR. TIME; 

RESULT_TyPE; 

float; 

INPUT_TYPE; 


begin 

for  INDEX  in  1  . .  N  loop 

put_line( "Enter  the  coefficients  and  "  & 

"right  hand  side  for  equation  "  & 
integer ' iroage( INDEX) ) ; 
for  NUM_C0EFF  in  1  . .  N  loop 

ge t  Tl  NPUT . COEFF I C I ENTS (INDEX, NUM_COEFF ) ) ; 
end  loop; 

get ( INPUT . RI GHT_HAND_S I DE ( I NDEX ) ) ; 
end  loop; 

for  INDEX  in  1  . .  N  loop 

INPUT. X0LD( INDEX)  0.0; 
end  loop; 

put ("Enter  tolerance  factor  =>  "); 
get(INPUT.TOL); 

put( "Enter  the  computation  duration  in  seconds  =>  "); 
get(COMP_TIME); 

put_line( "Synchronous  Jacobi  test  starting..."); 

DEAD  :=  CALENDAR. CLOCK  f  DURATION ( COMP_T I ME ) ; 

I MPCALL ( MY_TASK_PTR , 

1, 

DEAD, 

INPUT, 

RESULT ) ; 

put_line( "Jacobi  TEST  ending...  "); 
for  INDEX  in  1  . .  N  loop 
put("X"); 

put (INDEX, WIDTH  »>  1); 
put("  =>  "); 

put (RESULT (I NDEX),  EXP  =>  0); 
new_line. 
end  loop; 

end  SYNCHRONOUS_JACOBI_TEST; 
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with  CALENDAR;  use  CALENDAR; 

with  SYSTEM;  use  SYSTEM; 

package  ASYNCHRCi;OuS_JACOBI_COMPUTATION  is 

N  :  constant  integer  3; 

type  RESULTJTYPE  is  array  (1  ..  N)  o£  float; 
subtype  ERRORJTYPB  is  integer; 

type  COEFPICIENT.TYPE  is  arrayd  . .  N,  1  . .  N)  of  float; 

type  INPUT_TYPE  is  record 

COEFFICIENTS  :  COEFFICIENT_TYPE; 

RIGHT_HAND_SIDB  ;  RBSULTJTYPB; 

XOLD  :  RBSULT.TYPB; 

TOL  :  float; 

end  record; 

task  type  TBST_TASK  is 
pragma  PRIORITY(O); 

entry  START_COMPUTATION( INPUT  :  in  INPUT_TYPB); 
end  TBST_TASK; 

type  TBST_PTR  is  access  TESTJTASK; 

procedure  START_COMPUTATION(THB_TASK  :  in  TBST_PTR; 

INPUT  :  in  INPUT_TYPB); 

procedure  HANDLE ( LAST.VALUB  :  in  out 

RESULT_TYPE; 

LAST_ERROR_INDICATOR  :  in  out 

BRROR_TYPB); 


end  AS YNCHRONOUS _J ACOB I _COMPUTAT I ON ; 
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with  TEXT_IO;  use  TEXT_IO; 

with  FLOAT_TEXT_IO;  use  PLOAT_TEXT_I 0 ; 

with  INTEGER_TEXT_IO;  use  INTEGER  TEXT_IO; 

with  ASyNCHRONOUS_JACOBI_IHPRECISE_COHPUTATION; 

use  ASyMCHRONOUS_JACOBI_IHPRECISE_COHPUTATION; 

package  body  ABYNCHRONOUS.JACOBI.COMPUTATION  is 

procedure  START_COMPUTATION(THE_TASK  :  In  TEST_PTR; 

INPUT  :  In  INPUT_TYPE)  is 


begin 

THB_TASK . START_COMPUTATI ON ( I NPUT ) ; 
end  START_COMPUTATIOH; 

procedure  HANDLE ( LAST_VALUB  :  in  out 

RESULT_TyPE; 

LAST_ERROR_INDI GATOR  :  in  out 

ERROR_TyPE)  is 

begin 

put ( "Computation  looped  "); 
put ( LAST_BRROR_I NDICATOR ) ; 
put_line("  times."); 
end  HANDLE; 

task  body  TEST_TASK  la 


FINISHED 

ERROR 

COEFF 

R_H_S 

XOLD 

TOL 

XNEW 

C 

D 

MAXNEV, 

NNBW, 

MAXDIF, 

DiFF 


boolean  false; 

ERROR_TyPE  :»  0; 
COEFFICIENT_TyPE;  — 
RESULT_TyPB; 
RESULT_TyPE; 
float; 

RESULTjryPE; 
COEFFICIENTjryPE;  — 

RESULT_TyPE7 


coefficient  input 
right-hand-side 
solution  guess 
tolerance 

new  solution  vector 
norm  input  coeff 
normalized  r  h  s 


—  "new"  in  text  but  reserved 
:  float; 


begin 

accept  START_COMPUTATIOH( INPUT  :  in  INPUT_TyPE)  do 
COEFF  ;*  I NPUT. COEFFICIENTS; 

R_H_S  ;«  INPUT.RIGHT_HAND_SIDE; 

XOLD  I NPUT. XOLD; 

TOL  ;=  INPUT. TOL; 
end  START_COMPUTATION; 
delay  duration'small; 

—  Normalize  matrix  — 
for  J  in  1  . .  N  loop 

for  K  in  1  . .  J  -  1  loop 
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C(J,K)  :■  COEPP(J,  K)  /  COEPP(J,  J); 
end  loop; 

£or  K  in  J  -t-  1  . .  M  loop 

C(J,K)  :=  C0EPP(J,  K)  /  COEPP(J,  J); 
end  loop; 

D(J)  ;»  R_H_S(J)  /  C0EPP(J,  J); 
end  loop; 

—  Iterate  improvement  until  required 

—  accuracy  is  achieved 

loop 

MAXNBV  :>  0.0; 

MAXOIP  0.0; 
for  J  in  1  . .  N  loop 
XMEV(J)  :=  D(J); 
for  K  in  1  . .  J  -  1  loop 

XNEV(J)  XNEV(J)  -  C(J^K)  *  XOLD(K); 
end  loop; 

for  K  in  J  -f  1  . .  M  loop 

XNEW(J)  :»  XNEW(J)  -  C(J,K)  *  XOLD(K); 
end  loop; 

—  Pind  max  absolute  difference 
—  betvreen  old  and  new  elements. 

DIPP  :»  ABS(XNEW(J)  -  XOLD(J)); 
if  DIPP  >  MAXDIF  then 
MAXDIP  OlFF; 
end  if; 

NMEW  :«  ABS(XNEV(J) ); 
if  MNEW  >  MAXNEW  then 
MAXNEW  :=  NNEV; 
end  if; 
end  loop; 

—  Let  present  estimate  be  improved  estimate 
XOLDd  ..  N)  XNEWd  ..  N); 

ERROR  :»  ERROR  •»-  1; 
if  MAXNEW  /»  0.0  and  then 

(MAXDIP  /  MAXNEW)  <=  TOL  then 
FINISHED  TRUE; 

end  if; 

IMPRETURN(XNEW,  ERROR,  FINISHED); 
exit  when  FINISHED; 
end  loop; 

exception 

when  CONSTRAINT_ERROR  I  NUMERIC.ERROR  »> 

put_line( "NUMERIC  ERROR  -  Diverging  solution"); 

end  TEST_TASK; 

end  AS YNCHRONOUS_JACOBI .COMPUTATION; 


with  ASYMCHROMOUS_JACOBI_COHPUTXTION; 
use  ASYNCHRONOUS_JACOBI_CCMPUTATIOK ; 
with  AS YNCHRONOUS _I HPRBC I S B.COHPUT AT ION; 
package  ASYMCHRONOUS_JACOBI_IMPRBCISB_COHPUTATION  i 
new  AS YNCHRONOUS.I HPRBCI SE_COHPUTATI ON 
(COMPUTATION  =>  TB8T_TASK, 

COMPUTATION_PTR  =>  TEST_PTR, 

RESULT_TYPE  »>  RESULT_TYPE, 

ERROR_INDICATOR_TYPE  *>  ERROR_TYPB, 

INPUT_TYPE  *>  INPUT_TYPE, 

START_COMPUTATION  »>  START_COMPUTATION, 

HANDLE  ->  HANDLE); 
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with  ASYNCHRONOUS.JACOBI.COMPUTATIOM; 
use  AS  y NCHRONOUS.J ACOBI _COMPUTATI ON ; 
with  ASYNCHRONOUS_JACOBI_IMPRECISB_COMPUTATION; 
use  ASYNCHROMOUS.J ACOBl _I MPRBCI SB.COMPUTATI ON ; 
with  CALENDAR;  use  CALENDAR; 

With  TEXT_IO;  use  TEXT_IO; 

with  FLOAT_TEXT_IO;  use  FLOAT_TEXT  10; 

with  INTEGER_TEXT_IO;  use  INTBGiR_TEXT_IO; 

procedure  ASYNCHRONOUS_JACOBI_TEST  is 

pragma  TIMB_SLICE(0.01); 


TEST^PTR  :=  new  TBSTJTASK; 

CALENDAR. TIME; 

RESULT_TYPE; 
float; 

INPUT_TYPB; 

begin 

for  INDEX  in  1  ..  N  loop 

put_Iine( "Enter  the  coefficients  and  "  & 

"right  hand  side  for  eguation  "  & 
integer ' image( INDEX) ) ; 
for  NUM  COBFF  in  1  ..  N  loop 

get (INPUT. COEFP I Cl ENTS ( I NDEX , NUM.COEFP ) ) ; 
end  loop; 

ge t ( I NPUT . R I GHT_H AND_S I DE ( I NDEX ) ) ; 
end  loop; 

for  INDEX  ini  . .  N  loop 

I NPUT. X0LD( INDEX)  0.0; 
end  loop; 

put ("Enter  tolerance  factor  =>  "); 
get(INPUT.TOL); 

put ("Enter  the  computation  duration  in  seconds  =>  "); 
get(COMP_TIME); 

put_line( "Asynchronous  Jacobi  TEST  starting..."); 

DEAD  CALENDAR. CLOCK  *  DURATION (C0HP_T I HE ) ; 

IMPCALL ( MY_TASK_PTR, 

DEAD, 

INPUT, 

RESULT); 

put_line( "Jacobi  TEST  ending...  "); 
for  INDEX  in  1  . .  N  loop 
put("X"); 

put (I NDEX, WIDTH  »>  1); 
put("  ■>  "); 

put (RESULT (I NDEX),  EXP  »>  0); 
new_llne; 
end  loop; 

end  ASYNCHRONOUS.JACOBIJTEST; 


DEAD 

RESULT 

COMP_TIMB 

INPUT 
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